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1 

2 

3 BACKGROUND OF THE INVENTION 
4 

5 The present invention relates generally to a system for vending products or 

6 services by the use of a standard ID card, such as a driver's liceHse. 

I 

7 It is sometimes desirable to vend products or to provide services only after certain 

8 information has been provided by the consumer. For example, in order to vend age- 

9 restricted products, such as alcohol or cigarettes, the age of the consumer must be verified 

10 in advance of the purchase, typically by having the vendor visually check the consumer's 

11 driver's license to verify his date of birth. In another example, it may be desirable to 

12 vend gasoline to a consumer only after the validity of his driver's license has been 

M 13 verified. 

O 

□ 14 To make the vending process more efficient, it is desirable to electronically 

1^ 15 automate the receipt of such pertinent information from the customer. But this is 

"^4 16 generally only possible if the consumer has some form of identification capable of storing 

17 such information in an electronic form. When one reviews the forms of identification 

f , 18 typically held and carried by consumers, one finds two primary forms of identification — 

P 19 credit cards and driver's licenses. In this respect, "credit cards" should be understood to 

.jj 20 refer to other similar types of issued cards, such as debit cards, store-issued credit cards, 

2 21 bank-issued automatic teller machine (ATM) cards, and "smart cards" which contain 

22 integrated circuitry. However, both of these forms of identification have drawbacks 

23 when applied to automating the process of gathering information about the consumer in 

24 advance of the vending of products and services. 

25 Credit cards typically contain magnetic strips or integrated circuitry that contain 

26 some amount of consumer information. However, credit cards are of limited utility in 

27 facilitating the automated information gathering process discussed above. First, not all 

28 consumers carry credit cards, especially many younger consumers. Second, the 

29 electronic information contained on credit cards is not always sufficient to allow an 

30 assessment of the propriety of vending a particular product to a given consumer. For 

31 example, credit cards typically do not contain information concerning the consumer's age 
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1 or date of birth, a necessary piece of information for automating the vending of age- 

2 restricted products. Third, credit cards, especially store-issued credit cards, typically only 

3 allow for the purchase of those products or services sold by that store, and are therefore 

4 of limited utility. Fourth, the electronic information contained on credit cards is 

5 sometimes encrypted, or stored in formats unknown and undecipherable to the vendors. 

6 In short, credit cards, in their various formats, are generally not a suitable mechanism for 

7 gathering information about a consumer in advance of the vending of products and 

8 services. 

9 Driver's licenses present an attractive means of gathering consumer information 

10 because they are widely held. However, driver's licenses, like credit cards, have 

11 historically been of limited utility for this purpose. First, driver's licenses come in many 

12 different formats, with each state issuing its own unique license. This makes automatic 
^ 13 information gathering difficult for a vending system which is to operate on a nationwide 
3 14 (or intemational) scale. Second, not all states' driver's licenses contain a means for 
^ 15 electronically storing information about the consumer. For example, not all states issue 

16 driver's licenses that contain a magnetic strip element. Third, even as to the driver's 

IS 17 licenses that do contain electronic means of storing consumer information, the 

18 information may be limited, encrypted, or stored in formats unknown and undecipherable 

P 19 to the vendors, and thus suffer fi'om the same problems as credit cards. Fourth, even if 

20 driver's licenses were suitable to automate the information gathering process, they lack 

rf 21 the means for allowing consumers to pay for the purchase, and therefore have been of 

22 limited utility in automating the entire vending process. 

23 A specific problem already mentioned is the vending of age-restricted products. 

24 Most, if not all, states impose minimum age requirements for the purchase of certain 

25 products such as alcohol, tobacco products, and other age-restricted products. In order to 

26 purchase such products, the customer traditionally must present identification to the seller 

27 to verify his or her age prior to the transaction. The inability to verify the customer's age 

28 prevents age-restricted products fi-om being sold in vending machines in an automated 

29 fashion. This verification process is particularly problematic in the vending machine 

30 industry since vending machines, by their very nature, involve xmattended point-of- 

31 purchase transactions. Some examples of prior approaches to this problem or related 
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problems can be found in the following U.S. patents, all of which are incorporated herein 
by reference in their entirety: 4,884,212; 5,139,384; 5,146,067, 5,273,183; 5,352,876; 
5,371,346; 5,450,980; 5,523,551; 5,641,050; 5,641,092; 5,647,505; 5,696,908; 5,722,526; 
5,734,150; 5,774,365; 5,819,981; 5,859,779; 5,927,544; 5,988,346; 5,147,021; 4,982,072; 
4,915,205; and 4,230,214. 

Some prior art vending approaches, such as that of Sharrard, U.S. Pat No. 
5,722,526, have contemplated using drivers licenses or other identification cards to verify 
the customer's age. In the Sharrard system, a customer inputs money into the vending 
machine and makes his or her selection. Thereafter, the customer is prompted to input an 
identification card such as a state government issued identification card or a driver's 
license containing the customer's birth date. The vending machine either optically reads 
the written birth date on the face of the card, or reads the birth date data from a magnetic 
strip contained on the back of the card. A processor unit compares this data with the 
present date that is keyed into the vending machine by its operator, and determines 
whether the customer is of a sufficient age to purchase the product. 

Sharrard's disclosure notwithstanding, it is difficult to implement Sharrard's 
technique for age verification. As noted previously, not all driver's licenses contain 
magnetic strips, and even for those that do, age data may not be present on the strip or 
may be difficult to extract. Further, despite Sharrard's general disclosure of the idea of 
optically scarming a driver's license to extract age data, such a process is not disclosed or 
enabled in Sharrard, but is merely noted as a good idea. 

Some prior art approaches such as U.S. Patent No. 5,927,544, issued to Kanoh, 
suggests that age information can be "recorded on the [credit] card" to verify a vending 
customer's age for the purpose of vending age-restricted products, see Kanoh, Col. 4, 11. 
55-58, but the present inventors submit that such information is in fact rarely present on a 
standard credit card. Although consumer reporting agencies, such as TRW and Equifax, 
and other credit card companies such as VISA or MasterCard, store information in 
databases for a large number of consumers, conventional vending machines are unable to 
access such information to verify the age of a purchaser. Those prior art vending 
machines that have connectivity to such databases contemplate using the database to 
verify credit or password information, but do not disclose or suggest using such databases 
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1 to verify age. See Kanoh, Col. 4, 11. 37-42 (noting that the microprocessor in his vending 

2 machine enables "a credit card company to check credit card nimibers, personal 

3 identification code numbers, and other data via a communications link," but not 

4 mentioning age data). 

5 What is needed is a highly flexible system for vending products and services that 

6 (1) can be implemented on a nationwide (or international) scale, (2) is fully automated, 

7 (3) is capable of extracting necessary information from a consumer to assist in the 

8 vending process, and (4) is capable of remotely managing and updating an unlimited 

9 number of vending machines. Additionally, such a system would be further advantaged 

10 by (1) providing means for allowing for the payment of the products and services vended, 

11 (2) being implementable by making only minor modifications to otherwise standard 

12 vending equipment, and (3) having the capability to vend a wide array of products and 

13 services. Such a system is disclosed herein. 
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1 

2 SUMMARY OF THE INVENTION 

3 

4 Disclosed is a highly integrated and flexible system for vending products and 

5 services to consumers. The system receives information in advance of the vend by 

6 having the consumer insert an identification (ID) card, preferably a driver's license, into a 

7 point-of-purchase terminal (referred to as an Optical Scanning Unit (OSU) device). The 

8 OSU device preferably contains an Optical Scanning Unit (OSU), capable of scanning 

9 the textual and graphical information (such as a validation seal or other picture) on the ID 

10 card. The scanned information, such as the consumer's age, is then compared against 

11 optical templates present in the system (preferably in the OSU) to discern or verify the 

12 information on the ID card, and is then used by the system to enable or disable the 
^ 13 vending transaction. 

O 14 The system preferably contains several components that may be distributed on a 

^) 15 nationwide basis depending on the desired system functionality and geographic scope of 

16 the proposed system. To add flexibility to and to enhance the performance of the system, 

^ 17 a protocol that allows for the OSU devices to conmiunicate with the remainder of the 

18 system has been developed and is disclosed. Additionally, optical character recognition 

P 19 (OCR) algorithms have been developed and are disclosed to facilitate the analysis of the 

20 ID cards, a process that presents special problems not encountered in OCR analysis 

2 21 generally. Furthermore, a design for an OSU, capable of reading and interpreting optical 

22 data and magnetic strip data, is disclosed. 

23 In a related embodiment, the disclosed system allows a consumer's ID card to act 

24 as a smart card useable for purchasing a wide array of products and services, including 

25 food, gas, money, phone service, rental cars, etc., which are sold through the OSU 

26 devices connected to the system. The system may also be used to tap into or establish 

27 consumer accounts useable for paying for system products and services. The system may 

28 be used more generally to determine information about a person or consimier who 

29 accesses the system, for example, by tapping into law enforcement or immigration status 

30 databases after OSU analysis of their ID cards. Additionally, methods are disclosed for 

31 initializing an OSU device upon its installation in the system and for configuring and/or 
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1 update its functionality. Because the ID card of different states may be used on the 

2 system, the system may be implemented on a nationwide scale. 
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1 

2 BRIEF DESCRIPTION OF THE DRAWINGS 

3 

4 Figure 1 shows a block diagram of the system. 
5 

6 Figure 2 shows a plan view of the optical scanning unit (OSU), including the face plate. 
7 

8 Figure 3 show a plan view of the left side of the OSU, with the face plate removed. 
9 

10 Figure 4 show a plan view of the top side of the OSU, with the face plate removed. 
11 

12 Figure 5 show a plan view of the right side of the OSU, with the face plate removed. 



lT 13 



□ 14 Figure 6 shows a schematic showing the relationship of the components in the OSU. 

ffl 15 

16 Figure 7 shows an illustration of the interaction of the various layers utilized in the Davis 



m 

4^ 17 Terminal Protocol 



M 18 

CJ 19 Figure 8 shows an exemplary driver's license capable of being optically analyzed by the 

ijj 20 system. 

□ 

rf 21 

22 Figure 9A shows an exemplary form and cluster information file structure used during 

23 optical character recognition (OCR). 
24 

25 Figure 9B shows an exemplary font information file structure used during optical 

26 character recognition (OCR). 
27 

28 Figure 10 shows the intemal structure of the Davis system server cluster 18 and the 

29 relationships between the various data structures therein. 

30 

31 Figure 1 1 shows a portion of the system disclosed in Figure 1 . 
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1 

2 Figure 1 2 shows a prior art vending machine. 
3 

4 Figure 13 shows a modification to the circuitry of the vending machine of Figure 9 to 

5 accompany an OSU. 
6 

7 Figure 14 shows a schematic of the circuitry of a vending machine modified to 

8 accompany an OSU. 
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1 

2 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

3 

4 In the disclosure that follows, in the interest of clarity, not all features of actual 

5 implementations are described. It will of course be appreciated that in the development 

6 of any such actual implementation, as in any such project, numerous engineering and 

7 design decisions must be made to achieve the developers* specific goals (e.g., compliance 

8 with technical- and business-related constraints), which will vary from one 

9 implementation to another. Moreover, attention will necessarily be paid to proper 

10 engineering and design practices for the environment in question. It will be 

11 appreciated that such a development effort might be complex and time-consuming, but 

12 would nevertheless be a routine undertaking for those of skill in the art given the 
^ 13 disclosure in the present specification. 

a 14 

^ 15 L System Overview 

2| 16 Disclosed herein is a transactional, multi-tiered, networked information system, 

45 17 referred to as the Davis system. ("Davis" is an acronym for the "Detsky Age 

5 

l^j^ 18 Verification Information System"). The system includes a broad range of technology 

19 and uses relating to the sale and distribution of products and/or services. Many of these 

20 uses are disclosed herein, but one skilled in the art should recognize that the system 

21 disclosed herein is capable of many uses, none of which detract from the spirit of the 

22 disclosed inventive concepts. 

23 In a preferred embodiment of the system, the system includes a terminal 

24 accessible by a consumer, such as a vending machine, an automatic teller machine 

25 (ATM), a gas pump, a public phone, etc. This terminal contains a means for determining 

26 certain information about the customer relevant to the desired purchase. In a preferred 

27 embodiment, the terminal is able to receive a piece of identification from the consumer, 

28 such as a driver's license or other identification (ID) card. 

29 Preferably, but not exclusively, the consumer information is read from the ID card 

30 using optical scanning technology, the specifics of which will be disclosed later in this 

31 specification. Thus, the terminal includes an optical scanning unit (OSU) for receiving 
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1 the ID card and "reading" certain information from it. For example, assuming the 

2 terminal is a vending machine that vends age-restricted products such as cigarettes or 

3 alcohol, the consumer's age can be read from the ID card and processed by the system to 

4 determine the consumer's age and enable the purchase accordingly. If the terminal is a 

5 gas pump, the consumer's driver's license can be read and checked by the system to 

6 check its validity and enable the purchase of gas accordingly. If the terminal is an ATM, 

7 the consumer can use his ID card (as opposed to the more traditional, magnetic-strip debit 

8 cards issued by banks) to withdraw cash from his savings or checking account. Thus, the 

9 system allows a standard ID card, such as driver's licenses, to act as a "smart card," even 

10 if such card otherwise lacks the means for storing electronic data, such as on a magnetic 

11 strip or in integrated circuitry included on the card. These are just a few examples of the 

12 functionality of the system, all of which are made feasible by the OSU. 

1« 13 An overview of the components of the system 8 is shown in Figure 1 . One skilled 

y 

G3 14 in the art will immediately recognize that the system is suitably flexible that certain 

ff] 15 components in the system can be combined, eliminated, or added based on the desired 

16 functionality as dictated by the product or service to be marketed. 
«P 17 A. The OSU Device 10 

5 

1^,^ 18 The terminal with which the consumer reacts, and which contains (preferably) the 

U 19 optical scanning unit (OSU) 6 (see next section), is referred to generally as OSU device 

20 10. For example, OSU device 10 might constitute a vending machine, an ATM, a public 

21 phone, a gas pump, etc. 

22 The system 8 is capable of interfacing with several OSU devices 10, which may 

23 be connected to the system (e.g., to the OSU connection server(s) 12) by any means 

24 known in the art to connect electronic devices, such as by fixed cable, modem, wireless, 

25 or other networking means. The OSU device lO's primary function is to receive 

26 information from the consumer via its OSU 6 and to dispense products or services to the 

27 consumer (e.g., food, gas, money, etc.). Therefore, in accordance with the preferred 

28 embodiment, the consumer inserts his ID card into the OSU 6 on the OSU device 10, and 

29 a scanned image is taken of his ID card. This image may be sent to other parts of the 

30 system to be analyzed, such as the server cluster 18, using an optical character 

31 recognition scheme to be described in detail later, or the image data may be locally 
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1 processed at the OSU device 10. To avoid long transmission delays, it is currently 

2 preferable to process the image within the OSU device 10 itself. However, in the future, 

3 as higher bandwidth conmiunication systems are made available, it is contemplated that it 

4 may be preferable to process image data remotely at the servers. The OSU device 10 also 

5 performs other localized processing that need not be (or cannot be) performed by the 

6 remainder of the system. 

7 An OSU device 10 is typically manufactured with certain factory standard 

8 functionality. For example, if the OSU device 10 is a vending machine, the machine will 

9 come pre-progranmied to perform many of the functions standard to vending machines 

10 generally. However, the OSU device 10 may also be remotely configured or periodically 

1 1 updated as necessary either by the system 8, or locally by a portable computer or personal 

12 data assistant (PDA) device capable of interfacing with the OSU device 10. Remote 
Q 13 updating from system 8 is preferable due to its flexibility because it allows OSU device 
O 14 operators and owners to control updates via a web-based administration tool accessible 
gi 15 over the intemet. 

16 An OSU device 10 can be made to operate in "connection mode," "batch mode," 

=P 17 or "disconnect mode," or may be attached to other non-Davis systems components if 

s 

^ 18 necessary or desirable. When operating in connection mode, the OSU device 10 

H 19 constantly communicates with another portion of the system 8 to process certain 

20 consumer information. For example, analysis of the consimier's age, as determined 

O 

^ 21 Optically and/or using magnetic strip data from the consumer's driver's license, may be 

22 performed remotely by the system when operating in connected mode, although this is 

23 not presently preferred as previously mentioned. Connection mode is particularly useful 

24 for processing and validating consumer credit card information, which ideally should be 

25 performed during a consumer purchase transaction. 

26 When operating in batch mode, the OSU device 10 is not in communication with 

27 other portions of the system 8 during a consumer transaction. Instead, the OSU device 10 

28 may be made to connect to the system 8 during off-hours to process consumer 

29 information, or to receive update instruction from the system. However, as mentioned 

30 previously, it is currently preferred that consumer information is processed directly by the 

31 OSU devices 10. 
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1 When operating in disconnect mode, the OSU device 10 is configured and 

2 updated only when removed from service and attached to a PC or other device suitable 

3 for conununicating with the OSU device 10 "off line," such as a personal data assistant 

4 (PDA). In this sense, one skilled in the art should recognize that in a particular 

5 circumstance the OSU device 10 may be made to encompass all relevant functionality of 

6 the system 8, but without the benefit or necessity of communicating with a system or any 

7 other components. A good example of this would be an "age validation terminal" which 

8 could be installed in bars. In this embodiment, the consumer would simply insert his 

9 license into the terminal, most preferably in the presence of a bar attendant, at which 

10 point the terminal would perform an optical analysis of the license, and display a green 

11 light if the consumer's age is sufficient. In this embodiment, it may not be necessary to 

12 have the power of an entire networked system if the terminal itself is programmed off- 
^ 13 hours to provide suitable functionality. In this scenario, the bar attendant is spared the 
CiJ 14 potential discomfort of directly confronting the consumer about his age, and instead 

m 

15 could rely on the age verification information provided by the terminal. Such a terminal 

^ 16 may also prevent mistakes in age verification that otherwise might be made by the bar 

^ 17 attendant, or may be able to determine validity concerns with the license that might not 

B 

18 otherwise be discemable by the attendant. 
^ 19 The OSU device 10 may also be connected to other systems not normally 

y3 20 included in system 8. For example, the OSU device 10 can be made to communicate 

^ 21 with VisaNet (an on-line credit card service) to verify a consumer's credit card account 

22 information. Likewise, the OSU device 10 (or other parts of system 8) may be 

23 configured to dial into VisaNet during off-hours to reconcile transactions made during a 

24 specific day. Of course, should the OSU device 10 be made to connect directly with such 

25 third party systems, the method of communication may need to be programmed into the 

26 OSU device 10 and will not necessary be the same as the connection, batch or disconnect 

27 modes generally contemplated with respect to system 8. 

28 B. The OSU 6 

29 A preferred embodiment for the OSU 6 is shown in Figures 2-6. As will be 

30 explained later in this disclosure, OSU 6 can be incorporated into a standard or custom- 

31 made OSU device 10, such as a vending machine. 
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1 The OSU 6 in a preferred embodiment is a dual-fimction card reader, capable of 

2 reading both the textual and graphical data printed on the face of an ID card, and (if 

3 present) a magnetic strip. Because the OSU 6 can read both optical and magnetic data, it 

4 is capable of receiving a wealth of important data concerning the consumer from a 

5 number of different consumer ID cards, including driver's licenses and credit cards. In 

6 this regard, the OSU 6 can handle consumer transactions using ID cards that contain both 

7 optical information and magnetic information (which might be the case for some states' 

8 driver's licenses), or separate ID cards where one contains textual information and the 

9 other contains magnetic strip information. For example, the consumer's driver's license 

10 can be optically read to determine his age, and subsequently his credit card can be 

1 1 magnetically read to pay for a desired purchase. The preferred embodiment of the OSU 6 

12 is therefore extremely flexible. However, it should be noted that an OSU may function 

13 according to the inventive concepts disclosed herein even if it does not perform both 

□ 14 optical and magnetic reading functions. Thus, for a given application, only optical 

03 

15 reading may be required (e.g., if age verification was performed using only a driver's 

16 license, but payment was to be made with cash or through debiting of an account 
=p 17 established on the system 8), or only magnetic reading may be required. Additionally, an 

18 OSU 6 could also be easily modified by one of skill in the art to receive electrical data, 

19 e.g., as might reside in the integrated circuitry on a "smart card," in conjunction with any 
y3 20 combination of optical and magnetic data. 

^ 21 Figures 2-5 disclose plan views of the OSU 6 as viewed from different vantage 

22 points. In Figure 2, the face plate 200 is visible, which is the portion of the OSU 6 that a 

23 consumer would see from the outside of an OSU device 10, although this face plate 200 

24 has been removed from the other drawings for clarity. Face plate 200 contains a bezel 

25 202, which is essentially a slot for receiving the consumer's ID card. Also present on the 

26 face plate 200 are LCD display 203, which provides the consumer operating instructions 

27 and status information, and a cancel button/indicator light 204. LCD display 203 is 

28 preferably a 16 by 2 character display, but could be larger, or could constitute any other 

29 suitable means for displaying information, such as a cathode ray tube, a TFT flat panel 

30 display, etc. The face plate 200 also contains boh holes 206 for movmting the OSU 6 to 

31 the face of the OSU device 1 0. 
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1 Figures 2-5 show the internal structures of the OSU 6, including stepper motor 

2 208 with its associated gear 209, gear train 210, front and rear drives 212 and 214, 

3 charge-coupled-device (CCD) array 216, lamp 218, sensors 220, 221, and 223, magnetic 

4 head 225, and wires 219. Front and rear PC standoffs 222 and 224 are provided for 

5 mounting the printed circuit board (not shown for clarity) that contains the OSU 6's 

6 electronics, including microprocessor 230, Flash 232, and SRAM 234 (see Fig. 6). 

7 Although not shown, wires 219 are connected to a mating connector on the printed circuit 

8 board supported by the standoffs 222 and 224. The printed circuit board also contains an 

9 additional connector for connecting to the preexisting circuitry within the OSU device 10 

1 0 and for obtaining power. 

11 In operation, motor 208 controls and drives the gear train 210, which in turn 

12 controls the rubber-coated front and rear drives 212 and 214 to move the ID card 4 passed 
^ 13 the CCD array 216 for optical reading and the magnetic head 225 for magnetic reading. 

14 A suitable motor for this purpose is part no. PF42T-48, which is manufactured by Nippon 

S3 

01 15 Pulse Motors and which has a full step angle of 7.5°. Lamp 218 extends through the 

%| 

16 entire width of the OSU 6, and acts to illuminate the textual and graphical information on 

'P 17 the surface of the ID card 4 to create an image which is then picked up by the CCD array 

s 

18 216. A suitable lamp for use in OSU 6 is part no. BF386-20B, manufactured by JKL 

£3 

19 Components Corporation. A suitable CCD array is a 768 pixel by 1 pixel linear array 

'42 20 part no. TSL1406, manufactured by Texas Advanced Optoelectronics Solutions, Inc., 

Q 

^ 21 (TAOS). 

22 Also included within the OSU 6, but not visible in Figures 2-5, is the printed 

23 circuit board containing electronic control circuitry including microcontroller 230, flash 

24 memory 232, and static random access memory (SRAM) 234. As previously mentioned, 

25 this printed circuit board is connected to the standoffs 222 and 224, but has been removed 

26 from the Figures for clarity. Although the memory chips 232 and 234 can be used in a 

27 particular embodiment to hold a variety of data, in a preferred embodiment flash 232 

28 contains the configuration data for the OSU 6. Thus, flash 232 contains the program that 

29 defines the general operation of the OSU as well as contains the templates used by this 

30 program to determine the validity of the license, and to locate, for example, the date of 

31 birth information on the license. Flash 232 also contains the programs or algorithms 
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1 necessary to perform optical character recognition (OCR) on the received image data, 

2 e.g., to determine and interpret the "date of birth" field of the license. SRAM 234 

3 provides temporary storage of data obtained from the license, both optical and magnetic 

4 (if any), and provides general temporary storage for the microprocessor control system. 

5 An example of such temporary storage would be transaction information and batch 

6 information stored at the OSU prior to communication with the OSU CS 12. A suitable 

7 component for the microcontroller 230 is part no. SABC161PILFT, a 16-bit 

8 microcontroller manufactured by Siemens AG Semiconductor Division. A suitable 

9 component for flash memory 232 is part no. SST39SF040-70-4C, a 4 Megabit, 55 ns 

10 flash manufactured by Silicon Storage Technology, Inc. (SST). A suitable component for 

11 SRAM 234 is part no. TC554001AF71(Y), a 4 Megabit, 55 ns SRAM manufactured by 

12 Toshiba Corporation. 

^ 13 While it is currently preferable to scan, in a line by line fashion, the ID card under 

O 14 analysis to receive an image thereof, other suitable means of receiving an image are 

gi 15 contemplated. For example, the OSU 6 could be fitted with a digital camera device to 

16 take a "snap shot" of the ID card, instead of scanning line by line. As used herein, 

=p 17 "scanning" should therefore be understood as referring to line by line scaiming to procure 

L,j, 18 an image, or to other technologies akin to taking a picture or image of the ID card. 

19 The relation of the components in the OSU 6 is shown in schematic form in 

\§ 20 Figure 6. Also shown are the microcontroller 230's connection to communication device 

n 

21 236 (such as a modem), which as previously explained communicates with an OSU CS 

22 12, and its relation to the International Multi-Drop Bus 96, which is the bus internal to a 

23 standard vending machine, and which will be explained in further detail in a later portion 

24 of this disclosure. DEX (Direct Exchange) line 250 collects and conmiunicates 

25 information about the vending machine in which OSU 6 is installed. DEX is well known 

26 in the vending machine arts and is based on a protocol published by the European 

27 Vending Association. In vending machines supporting DEX, DEX data stored within the 

28 vending machine may be shared with external devices such as hand held computers or the 

29 remainder of system 8. This protocol thus allows route operators or machine owners to 

30 access information such as inventory status of the vending machine, transaction data. 
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1 metering data, and data pertaining to machine operation. An example of the latter would 

2 be temperature data for a machine supporting the vending of perishable food. 

3 With reference to Figure 6, the sequence of events occurring in the OSU 6 is 

4 exemplified for a typical transaction. In this example, it is assumed that the consumer 

5 uses a driver's license containing a magnetic strip, and that the consumer's age must be 

6 verified prior to allowing the purchase of an age restricted product from the OSU device 

7 10. It is also assumed that payment might be made by a credit card. Of course, an actual 

8 transaction implemented with the OSU 6 need not be so limited to these assumptions. 

9 When the consumer approaches the machine, display 203, under control of 

10 microcontroller 230, displays an instructional message, such as "please insert driver's 

11 license." The consumer complies by inserting his driver's license 4 into the bezel 202. 

12 When the front edge of the license passes first optical sensor 220, microcontroller 230 
p 13 Starts motor 208, which engages front drive 212 through gear 209 and gear train 210. 

14 Front drive 212 then quickly pulls the license into the OSU until the front edge of the 

II 15 license reaches second optical sensor 221 . During the transport of the license, the license 

16 is supported underneath by idler rollers (not shown in the Figures). 
4» 17 Once the second sensor 221 is reached, the OSU prepares to optically scan the 

a 

^ 18 information on the face of the license. At this point, lamp 218 is turned on to illuminate 

19 the face of the license, and the license is slowly advanced under CCD array 216 to 

y3 20 capture an optical image of the license. Suitably slow forward motion of the license for 

Q 

^ 21 scaiming is achieved by advancing the license .125 mils (one one-thousandth of an inch) 

22 per pulse of the stepper motor. Each step of the motor denotes what will ultimately be a 

23 line of single pixels in the stored driver's license image. Stepping and scanning the 

24 license occurs until the third optical sensor 223 is reached by the front edge of the 

25 license, at which point the license has been fully scanned. The line-by-line pixel data 

26 provided by the CCD array 216 is stored in SRAM 234 for fiirther processing. The entire 

27 optical scanning process takes about 4.3 seconds, but a scanning time of 3.0 seconds is 

28 desired in a commercial embodiment. During scanning, display 203 could be made to 

29 display a message such as "scanning license, please wait" to inform the consumer of the 

30 progress of the transaction. 
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1 After a slight delay, motor 208 is again activated, but in a reverse direction, i.e., 

2 such that the license is eventually ejected from bezel 202. During this ejection process, 

3 the information on the magnetic strip is read by magnetic head 225. Ejection and 

4 magnetic reading of the license is preferably performed at the motor's maximum speed to 

5 provide a maximum magnetic signal detectable by magnetic head 225. If magnetic data 

6 is present on the license, microcontroller 230 stores this data in digital form in SRAM 

7 234 along with the optical scanned data. 

8 At this point, the stored optical and/or magnetic data is processed, either locally 

9 by microprocessor 230 or by other components of the system 8 through communication 

10 device 236. To the extent data is processed by other components of the system 8, the 

11 OSU 6 waits for a response from OSU CS 12. If no response is received, the display 203 

12 might be made to state an appropriate response, such as "no server response, please try 
q 13 later," at which point the OSU 6 reverts to its idle or start condition. 

0 14 The optical data is first compared with the templates residing in flash 232. The 

01 15 purpose of this comparison is to find a template match that would indicate to the 

\\ 

g«j 16 microprocessor 230 in the OSU 6 that a valid driver's license has been presented for age 

4^ 17 verification and what issuing body (state or country) supplied the license. If no match is 

M 18 found, OSU 6 will interpret this result to mean that no age verification can be 

rr 19 accomplished using the optical data. If however a match is found, information associated 

4} 20 with the matching template will indicate where on the scanned image to look for detailed 

l^j, 21 information concerning the owner of the license, and more specifically, his date of birth, 

22 as will be explained in more detail later. Where the decision is to be made locally at the 

23 OSU 6, the OSU 6 need only to look at the date of birth and may not need to determine 

24 Other information about the consumer, such as name, driver's license number, etc. This 

25 date when compared to the current date (obtained from the real time clock in the OSU) 

26 will determine the age of the owner of the license. Preferably, optical character 

27 recognition of the name, address, driver's license number, and expiration date of the 

28 license will be sent to the server cluster 18 where additional checks can be made to 

29 fiirther verify age, license validity, and other necessary information. Additionally, where 

30 the driver's license contains magnetic stripe data, similar information may be sent to the 
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1 server cluster 1 8 prior to age verification, or may be used to further verify the information 

2 determined by optical analysis by comparing the optical and magnetic data. 

3 If either the OSU 6 or other portions of the Davis system 8 determines that the 

4 consumer's age is adequate, display 203 would display an appropriate message, such as 

5 "approved," and the display 203 would thereafter prompt the consumer to make payment 

6 to the OSU device 10, such as, by displaying the message "insert cash or credit card." 

7 This step might not be necessary if the consumer has a pre-registered account on the 

8 system connected to his driver's license, in which case his account would be debited 

9 accordingly. If a pre-registered account is to be the basis for payment, the optical 

10 recognition data obtained from the license will be sent to the server cluster 18 as a "key" 

11 to access the system account. 

12 The consumer then makes the payment, and the vending proceeds as it would in a 
Pj 13 Standard vending machine. If the consumer uses a credit card to pay for the purchase, the 

Q 14 OSU 6 scans the magnetic data using magnetic head 225, stores it in SRAM 234, and 

03 

gi 15 sends it to the OSU CS 12 to be processed, as will be explained in more detail later. 

16 Assuming the credit card is verified, the system will send an "approved" message to the 

^ 17 OSU 6, which will then instruct the consumer via display 203 to "select product." If the 

s 

18 credit card is not verified, or if insufficient credit remains on the card, the OSU 6 will be 

P 19 so notified by the system. In this case, the display 203 may state "not approved," and the 

lO 20 OSU 6 will return to its idle or start condition. Additionally, the OSU 6 preferably 

Q 

|4 21 reverts to its idle or start condition if any of the steps in the process take an inordinate 

22 amount of time. 

23 In any event, once payment has been made in a satisfactory manner, the OSU 

24 will generate a "vend enable" signal on "IMDB ouf line 240 in the vending machine to 

25 enable the purchase. After distribution of the product, the IMDB 96 internal to the 

26 vending machine will send a "vend complete" signal to microcontroller 230 on "IMDB 

27 in" line 242. At this point the batch buffer in SRAM 234 is updated, and a message such 

28 as "thank you for your purchase" is displayed by display 203 for a time. 

29 Later, for example, during off-hours, the OSU 6 will transmit the batch buffer to 

30 the OSU CS 12 for reconciliation, a process step which is particularly useful when 

31 dealing with a transaction where payment is made by a credit card. When a credit card is 
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1 presented for payment, it is presented before the product selection is made. The vending 

2 machine may have products being sold at various prices. Therefore, when the credit card 

3 is presented, the information on that card is sent to the server to obtain authorization for 

4 the purchase of unknown value. A preferable method to implement this credit 

5 authorization step is to request authorization for an amount that will allow the customer 

6 to select the highest priced item in the vending machine. Once authorization is 

7 completed, and when the customer selects a product, the price of that product is recorded 

8 in the batch buffer. This buffer, which lists all of the transactions occurring within the 

9 machine over some predetermined period of time, is transmitted to the OSU CS 12 at 

10 some time when the machine is not likely being used, say 2:00 AM. The server cluster 

11 18 ultimately sends the batch to a credit card server (such as FSS 14 or other integrated 

12 system 24) for reconciliation, whereby the credit card processing company compares the 
^ 13 amount authorized to the amoimt of the actual purchase and charges the credit card 

0 14 account for the actual amount of the purchase. Information concerning cash transactions 

03 

01 15 and DEX information, along with the credit card information, is also used by the server 

y 

16 cluster 1 8 for the generation of system or OSU device 1 0 reports. 

17 As mentioned earlier, the OSU device 10 can also operate in a batch or disconnect 

18 mode, such that the OSU device is either temporarily or permanently disconnected from 

pa 

r"; 19 the system. Operation in these modes may be intentional or may be inadvertent, such as 

'4^ 20 when the system is not functioning or if commimication between the system and the OSU 

21 device 10 is compromised. In either of these modes, the above flow would be modified 

22 accordingly. First, age validation would have to occur locally within the OSU 6, which 

23 might increase the processing power or amount of data storage that would be necessary in 

24 the OSU device 10. (As will be explained later, optical verification of a driver's license 

25 involves the use of algorithms and comparison with image templates, which generally 

26 increase the computing power needed for the verification function). 

27 Second, the ability to verify the validity or creditworthiness of a credit card could 

28 not be made during the process of the transaction. In this circumstance, and if the system 

29 is not responding, payment is preferably handled in two ways. First, the OSU 6 could be 

30 configured to receive only cash payments. Second, the OSU 6 could additionally be 

31 configured to receive a credit card. In this latter case, the OSU 6 is preferably configured 
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1 to analyze as much information as is possible to try and validate the transaction. Thus, 

2 with the assistance of the microcontroller 230 and information about correct credit card 

3 data format stored in memory within the OSU 6, the OSU 6 assesses the form of the 

4 credit card data and the expiration date. If acceptable in format, the credit card purchase 

5 can proceed. If not acceptable, the consumer may be instructed to pay for the purchase 

6 by cash. The transaction and credit card data would be stored in the OSU 6's memory to 

7 be later sent to the system or retrieved by an operator to be processed. 

8 C. The OSU Connection Server 12 

9 OSU connection server (OSU CS) 12 communicates with OSU devices 10 using a 

10 bi-directional "Davis Terminal Protocol" (DTP) 26, the specifics of which are discussed 

11 later in this specification. Essentially, the OSU CS 12 acts as a bridge or proxy for OSU 

12 devices 10 with respect to their communication with server cluster 18. The OSU CS 12 

13 can simultaneously handle bi-directions communication with one or many OSU devices 
O 14 over any transmission means capable of supporting DTP 26. One skilled will recognize 

15 that OSU CS 12 could constitute a cluster of several servers to prevent any particular 

16 server from becoming overworked and to provide redundancy in case a particular server 
4« 17 fails. The OSU CS 12 can also be locally or geographically dispersed to enhance system 

B 

yL 18 reliability and robustness. 

19 Every time an OSU device 10 queries the system, or the system provides 

20 information to the OSU device 10, an "OSU CS session" is created. In this manner, the 

6 

^ 21 OSU CS 12 handles communication between the OSU devices 10 and the remainder of 

22 the system. The OSU CS 12 can be any suitable server, but in a preferred embodiment 

23 constitutes any system that supports the Java 2 platform. Preferably a commercial 

24 embodiment will use an x86 based server running linux 2.4 kemal with extemal modems 

25 connected through standard RS232 serial ports. Although several means of 

26 communication are possible between the OSU CS 12 and the remainder of the system 

27 (e.g., server cluster 18), it is presently preferred to use Java 2 Enterprise Edition (J2EE) 

28 over a TCP/IP connection to establish this communication link. 

29 Depending on the application, OSU CSs 12 may not be necessary, and the OSU 

30 devices 10 could instead communicate with the server cluster 18 directly or by any other 
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1 system using the Davis Terminal Protocol (DTP), which will be described later, or any 

2 other suitable protocol. 

3 D. Server Cluster 18 

4 Server cluster 18 essentially functions as the operating system of the Davis system 

5 8. It provides, among other things (1) services to manage the OSU devices 10 and their 

6 associated OSU CSs 12, (2) storage for data used by the system, (3) web (intemet) 

7 application functionality, (4) connectivity to off-system services like VisaNet, and (5) 

8 other integrated e-business systems. 

9 One skilled in the art will recognize that server cluster 18 can include databases 

10 for storage of necessary system and consumer data, and that such databases can be 

11 integral with or separate from the servers in the cluster. In a preferred commercial 

12 embodiment, server cluster 18 comprises (1) four Compaq Proliant systems running 

13 RedHat Linux 7.1 with the 2.4 Linux kemal, (2) two servers, each with IGM of RAM 
□ 14 and 50GB of mirrored disk storage provided hosting tasks utilizing JBOSS 3.0 J2EE 
QT 15 protocol, and (3) two additional servers, each with 256MB RAM, 25GB mirrored disk 

16 storage, and dual external USRobotics modems, for providing hosting tasks to an OSU 

»P 17 CS 12. In the preferred embodiment, the four modems are assigned to a single number 

L,j, 18 call pool to which the OSU devices 10 connect. The modems preferably answer calls in a 

19 round robin fashion such that if one modem is busy another one in the pool answers the 

20 call. However, it should be recognized that while a cluster of networked servers is 

C3 

^ 21 beneficial to handle overload and to provide redxmdancy in the event of server failure, 

22 server cluster 1 8 could constitute a single server in a given application. 

23 E. Management Console 22 

24 The management console 22 is essentially the terminal by which the Davis 

25 system's administrator accesses the network. In a preferred embodiment, management 

26 console 22 constitutes any suitable personal computer or workstation and provides the 

27 administrator a user interface for accessing the system. From this console 22, the 

28 administrator can list, group, and report information about the various OSU devices 10. 

29 For example, assuming the OSU devices 10 are vending machines, the administrator can 

30 determine if any of the machines are ruiming low on product. Furthermore, console 22 

31 can be used to configure and deploy software updates for the OSU devices 10 and/or 
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1 other system components. For example, it is from this terminal that the administrator 

2 would deploy a new template specifying the configuration of a particular driver's license 

3 (e.g., the state of Texas), so that the system and the OSUs will know how to optically 

4 recognize and analyze such a license format. 

5 In a preferred embodiment, limited system administration functionality is 

6 available to vending machine or other OSU device 10 operators. In this embodiment, 

7 each operator is assigned its own user profile and management console for logging into 

8 the system, from which they could add, edit, delete, inactivate, pulls reports on, etc., the 

9 OSU devices 1 0 under their control. 

10 F. Monitor 16 

11 Monitor 16 monitors and maintains communication with critical system functions 

12 to increase system reliability. Monitor 16 provides manual and automated means to 
^ 13 observe system functions and respond to system errors. For example, if an OSU CS 12 or 
Q 14 OSU device 10 ceases to function properly, monitor 16 detects this error and responds 

15 appropriately. Thus, the monitor 16 may reroute conmiunications to a working or 

16 redundant OSU CS 12, or page the system administrator. In the event of less critical 
«p 17 system errors, monitor 16 may simply record the systems error in a system log that may 
l^x, 18 later be addressed by the administrator. 

£| 19 Monitor 16 registers when a component of the system has come on line. In this 

di 20 respect, system components may broadcast their presence on the system to be picked up 

n 

^ 21 by monitor 16, or the components may be configured to register themselves on monitor 

22 16 without further assistance. Once registered and on line, components preferably "ping" 

23 monitor 16 at regular intervals to provide a "heart beat" for the system. Monitor 16 may 

24 also request a ping or may request information about system functions. For example, the 

25 monitor may request an OSU CS 12 to provide the number of active connections with 

26 various OSU devices 10 and duration of each connection. In a preferred embodiment, 

27 monitor 16 constitutes a server similar to the OSU CSs 12 as described above. 

28 G. Financial Services System 14 

29 Financial Services System (FSS) 14 provides the system the ability to process 

30 account transactions, i.e., the ability for consumers to access their financial accounts in 

31 order to make purchases or receive other services on the system. 
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1 Several examples exist of financials services supportable by the system. For 

2 example, FSS 14 could constitute a credit card payment service, such as VisaNet. In such 

3 an embodiment, the consumer would input their credit card into the OSU device 10 and 

4 credit for the consumer's purchase would be effectuated and processed through VisaNet. 

5 If the system contains information linking a particular ID card (e.g., a license) to a credit 

6 card, such processing may also occur by simply having the consumer enter his ID card 

7 into the system, which effectively allows the ID card to work as a credit card on the 

8 system. 

9 Additionally, FSS 14 could constitute an aggregation of several accounts of the 

10 consumer, such as his credit/debit card accounts or checking or saving accounts. All of 

11 these accounts, if registered by the consumer on the system, may be accessible through 

12 the system 8 as part of FSS 14. This embodiment allows the system to function as an 
p 13 ATM, whereby a consumer enters his ID card into an OSU device 10 and can withdraw 
Q 14 money from his accoxmt or perform other financial transactions with his accounts without 

m 

gi 15 using his designated bank debit card. In this embodiment, the OSU device 12 might 

16 constitute an ATM machine fitted with an OSU. Likewise, an OSU could be 



3 



17 incorporated with cash registers or other point-of-sale machines to effectuate consumer 

U 18 purchases, and allow the consumer access to several of his accounts using a single ID 

H 19 card. Thus, by using his ID card at a point-of-sale terminal, the consumer can be 

pi: 

yi 20 presented with a list of accounts registered on the system, and may select an account to 

□ 

1^ 21 pay for the purchase. 

22 In another embodiment, FSS 14 constitutes a Davis cash account set up by the 

23 consumer for use on the system 8. This embodiment is envisioned as being particularly 

24 useful in the marketing of low cost items such as candy bars. For such transactions, it 

25 may not be sensible to pay for the purchase with a credit card, as the credit transaction 

26 fees may be relatively expensive when compared to the cost of the item being purchased. 

27 Using FSS 14, a consumer cash accoxmt can be established from which payment 

28 for purchases on the system will be drawn. Thus, the system could be used, again in 

29 conjunction with the FSS 14, to transfer funds from the consumer's bank accoimt to the 

30 cash account, or the cash account could be established by other means, such as sending a 

31 check to the system administrator. Thereafter, when the consumer enters his ID card into 
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the OSU device, credit for the purchase will be drawn from his cash account, or the OSU 
device 10 may present the consumer an option to either have the money so drawn or to 
provide cash payment to the OSU device 10. Such an embodiment is believed 
particularly suitable for vending machines, pay phones, slot machines, transportation 
ticket dispensers, stamp machines, etc. In this respect, it is important to note that the 
system has flexibility and utility beyond age verification. In other words, the system 
need not be used exclusively to vend age-restricted products, and whether age 
verification is required for a particular purchase transaction can be easily controlled by 
enabling or disabling such functionality using the system. 

When dealing with consumer accounts on the Davis system, it is generally 
preferred that such accounts be accessible through the use of a personal identification 
number (PIN) to ensure security. In this regard, the OSU device 10 will contain a 
keyboard or other suitable means for allowing a PIN number to be entered after receipt 
and optical analysis of the ID card. Suitable PIN numbers may be distributed by 
traditional means by an administrator of the Davis system. Optionally, and more 
generally, a "private key'' could be used to ensure security, which could comprise a PIN 
number, some sort of biometric input such as a finger print, a code generation device 
containing an internal clock and encrypted algorithms for generating an access code, etc. 

H. User Interface 20 

User interface 20 generally constitutes a personal computer from which registered 
consumers can access certain system features, and may be as numerous as the number of 
consumers that use the system. For example, using interface 20, a consumer can log onto 
the system (preferably via the web or internet) to set up a system cash account, to transfer 
funds between registered accounts, or to check fund balances. Interface 20 can also be 
used to check product availability at a particular OSU device 10, to check their statuses, 
e.g., whether such devices are functional at the present time, or to check for the location 
of OSU devices 10 connected to the system. For security reasons, it is contemplated that 
consumers be issued passwords and user names that enable them to log on to the system. 

Suppose a consumer wishes to use his driver's license to purchase products for 

sale on a given Davis system. Using user interface 20, the consumer can log onto the 

Davis system website and register her driver's license by inputting pertinent information 
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After creating an on-line account by logging into a user interface 20, he can access to his 
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home page on the system and register each of the 20 vending machines. When the 
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registered devices call into the Davis system, they can synchronize with the operator- 




31 


configured settings. For example, the devices can be directed to dial in once a week to 
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1 provide DEX, audit, or reporting data. From this information the operator is able to 

2 manage inventory, add optical scanning templates so that the devices will recognize 

3 inserted ID cards, and generally control the functionality of his OSU device 10. 

4 I. Integrated Systems 24 

5 One skilled in the art will recognize that the system 8 could be made to interface 

6 with other integrated systems 24 to improve or enhance system performance. Examples 

7 of integrated systems 24 include VisaNet, law enforcement agencies, etc., and enable the 

8 system to act as a subscriber (i.e., to receive information from other systems), a provider 

9 (i.e., to provide information to other systems), or a transaction partner (e.g., with 

10 VisaNet). Certain systems constituting FSSs 14 may also constitute examples of 

1 1 integrated systems 24. 

12 J. System Geography 

^^13 It is contemplated that Davis system 8 could be deployed on a nationwide or 

□ 14 international basis. Such flexibility is realizable because the system has the capability of 

03 

gt 15 recognizing ID cards issued from several different jurisdictions. In such an embodiment, 

^ 16 it is preferred that the OSU devices 10 be located nationwide, that OSU CSs 12 be 

«P 17 located in certain local regions (such as cities) such that they are capable of serving 

u 18 several different OSU devices 10 within their locales, and that the server cluster 18, 

P 19 monitor 16, and management console 22 be located at a "headquarter" location in the 

%Q 20 vicinity of the Davis system administrator. Of course, user interfaces 20, FSS 14, and 

21 integrated systems 22 will likely exist somewhere distant from headquarters. Smaller 

22 more regional systems are also possible, and the disclosed preferred geographical 

23 distribution of the system may be easily be modified depending on system requirements. 

24 

25 11. Davis Terminal Protocol (DTP) 

26 As previously mentioned, a specialized protocol is used in the communication 

27 between the OSU devices 10 and the OSU cluster servers (OSU CS) 12 called the Davis 

28 Terminal Protocol (DTP) (see Figure 1, element 26). After researching several available 

29 communication protocols it was determined that none of them met the requirements for 

30 the Davis system 8, such as: 
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DTP nrovides a laver of abstraction that insulates OSU device develooment from 
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current nrotocols and their evolvement 
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communication. DTP, however, may also be used in future embodiments to allow 
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with regard to the size of data to be transmitted. Therefore, larger or smaller 
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pieces of data may be sent depending on the bandwidth available. Packet oriented 
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"liffhtweiaht"* DTP transmits data with little nrotocol-related overhead 
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on the data transmission requirements. It is therefore advantageous to be able to 




28 




quickly implement a new device that is able to conununicate with the server. 




29 




While TCP/IP was thought originally to be a suitable protocol candidate, it was 




30 




determined that this protocol was not suitably "lightweight," was not simple or 
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1 fast to implement, and did not provide an important abstraction layer for OSU 

2 software development. DTP squarely addresses these concerns, and was therefore 

3 determined to be a suitable candidate for use in the Davis system. One skilled in 

4 the art will notice however that DTP borrows certain technical concepts from 

5 TCP/IP, but tuned in such a way to make its implementation in the Davis system 

6 optimal. (Due to the limited resources of the modem-based communication 

7 channels that are preferably used in the system, it is not feasible at this time to use 

8 the standard TCP/IP or TCP/PPP protocols that requires wider bandwidth than 

9 DHP/DMP, but this may change as technology progresses.) 

10 In the current embodiment, the Davis system 8 uses the DTP protocol layered on 

11 top of the industry standard RS232 protocol for serial communications. DTP is itself 

12 composed of two layers: the Davis middle level protocol (DMP), and the Davis high level 
^ 13 protocol (DHP). Written together, communication protocol for the Davis system thus 

O 14 consists of a DHP/DMP/RS232 stack, although any lower level communication protocol 

03 

15 could support the DHP/DMP stack disclosed herein. It is currently preferable in a 

16 commercial embodiment to use the V22 modem protocol, and thus the entire 
4^ 17 conmiunication stack may be written as DHP/DMP/RS232/V22 or simply DTP/V22. 
^ 18 Later, DTP can easily be upgraded in a commercial embodiment to the DTP/TCP/IP or 
r" 19 DTP/TCP/PPP combinations when technological advances allow. 

^3 20 The different layers in the DHP/DMP construction perform different functions 

Q 

1,1, 21 independent of the other layers. Each layer of the protocol performs services for the layer 

22 above it and provides services to the layer below it. When two devices are 

23 communicating, each layer of the protocol stack communicates with the same layer of the 

24 protocol stack on the other device. Figure 7 identifies three distinct communication 

25 phases that are utilized in DTP. In Phase 1, an OSU device 10 communicates with the 

26 Davis server system (i.e., either OSU CS 12 or server cluster 18) and requests one of its 

27 services. It does so by calling one of the routines available in the DHP API (application 

28 programming interface). The DHP routine in turn forwards the request to the DMP layer. 

29 The DMP layer then forwards or repackages the request on to the native communication 

30 channel such as RS232 (and preferably V22). In Phase 2, the native conmiunication 

31 channel relays the request from the OSU Device 10 to the Davis server system. In Phase 
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1 3, the Davis server system accepts the request and forwards it on to the receiving DMP 

2 layer. The DMP layer then passes the request on to the DHP layer, followed by the OSU 

3 CS 12 proxy ing the request on to the server cluster 1 8. 

4 The three phases will repeat, now in the reverse direction, to allow the system to 

5 send a response to the OSU device 10. While this example assumes that the OSU device 

6 10 has made the request to the system, the system may also make requests to the OSU 

7 device 10, thus allowing for asynchronous, bi-directional communication. 

8 The DHP and DMP provide communication services independent of one another, 

9 and hence generally provide different functionality. Preferably, DHP provides APIs such 

10 as login requests, transaction requests, and update requests. By contrast, DMP provides 

1 1 for data packet field and segment definitions, handshaking, and other lower level tasks. 

12 A. DMP 

Lb 

13 DMP provides reliable, full-duplex, byte stream-oriented service. It accepts data 



14 from the DHP layer, divides DHP segments into a set of DMP segments and adds a 

S3 

Ql 15 header to each segment, and sends individual segments to the modem. If the size of a 

g-| 16 segment exceeds the maximum pay load capacity, DMP divides the segment into several 

17 segments and sets the sequence niunber field in the header for the benefit of the receiving 

s 

y, 18 system. The capacity of DMP data payload varies from 0 to 255 bytes per segment, 

r: 19 DMP is also free to retransmit a single segment of 200 bytes as two segments each 

20 containing 100 bytes of data. 

21 When a transmitted segment is received by the other system (e.g., OSU CS 12), 

22 DMP checks the sequence number in the header to verify that nxmiber of segments that 

23 carry a particular unit of data. When the expected number of segments is received, the 

24 receiving system retains the data for analysis or other processing and sends an 

25 acknowledgment back to the sending system (e.g., OSU device 10). The acknowledgment 

26 field in the header of the acknowledgment message contains the sequence number in the 

27 received data segment. To verify that a segment was received without errors, DMP uses 

28 the checksum field, which contains the sum of all segment bytes, with the exception of 

29 the last two bytes containing the check sum. 

30 The preferred format for the DMP data segments is shown in the below table 



31 
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01 



BMP Header Format 


Field 


SizefbUs) 


Description 


Version 


1 


Specifies the protocol version and verifies that 
the sender, receivers are using a current 
version of the protocol. Preferably 0x01 . 


ACK Flag 


1 


1 if the previous segment was received 
without errors. 


Sequence Number 


8 


Identifies the position of the data in the 
senders bit stream. 


Acknowledge Number 


8 


The number of the last received sequence. 


Length 


8 


Specifies the length of the data in bytes. 


Data 


Varies 




Checksum 


16 


The sum off all the bytes in the segment (used 
for error correction) 



1 

2 B. Handshaking 

3 When an OSU device 10 and a server desire to communicate, they must first 

4 "handshake." DMP uses a 2-way handshake to initiate a connection, a process that 

5 ensures that both devices are ready to transmit data, and that both devices know that the 

6 other is ready to receive data before the transfer actually starts. The procedure works as 

7 follows: sending device A (e.g., OSU device 10) sends a segment to device B (e.g., OSU 

8 CS 12) wherein Sequence Number = 0, and ACK_FLAG = 0. When device B receives 

9 the segment from device A, and if device B is ready to communicate with A, it sends a 

10 segment to A wherein Sequence Number = 0, Acknowledge Number = 0, and 

1 1 ACK_FLAG = 1 . Thereafter, device A may transfer data to device B. 

12 Note that a segment may be sent or received fi'om either end at any time. If an 

13 acknowledgment (i.e., ACK_FLAG = 1) is not received for a non-zero length segment 

14 after a timeout of 2 seconds, the segment will be retransmitted. If the segment was 

15 retransmitted 3 times and the acknowledgment was not received, the connection is 

16 terminated. 

17 C DHP 

18 Like DMP segments, every DHP segment has a structure that includes a header 

19 and associated data. With respect the DHP header, the first byte (i.e., eight bits) specifies 

20 the version of DHP protocol (4 bits) and type of data (4 bits). The next word (16 bits, or 

21 two bytes) specifies the length of the data within the segment, which preferably can be as 
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1 

2 



large as 64K bytes. The rest of bytes in the segment constitute the data. This segment 
structure is shown in the below table: 



b 



a 



DHP Header Format 


Field 


Size (bits) 


Description 


Version 


4 


Version of the DTP protocol. 


Type 


4 


Type of data: 

0 - Login Request 

1 - Login Response 

2 - Transaction Request 

3 - Transaction Response 

4 - Transaction Commit 

5 - Transaction Commit Response 

6 - Update Request 

7 - Update Response 
8 -DEX Submit 

9 - DEX Response 

1 0 - Logoff Request 


Length 


24 


Specifies the length of the data 


Data 


Varies 





3 

4 There are two types of DHP segments, those that store payload data in an ASCII 

5 string format and those that store data in a binary format. Binary format is a sequence of 

6 bytes used to represent any type of data, such as numbers, bit-map images, or complex 

7 data structures. String data is a sequence of bytes used to represent ASCII characters, 

8 which is a more convenient way to represent some systems data such as birth date, person 

9 name, or an ID number. An example of a string format might be "propertyNamel = 

10 value 1; propertyName2 = value2," and a more specific example for a "Transaction 

11 Response" packet may looks like "tm=1234567; time=09/27/01; err=0", where different 

12 properties are separated by a semicolon character and a property name and property 

13 value are separated by an equal sign character '='. Each of the eleven types of exemplary 

14 segments illustrated in the above table is summarized below, along with a description of 

15 their function. One skilled will realize that other segment types, carrying different forms 

16 of data for a variety of purposes, could easily be implemented, depending on the 

17 requirements of the application. 

18 • Type 0 - Login Request (string packet): Before an OSU device 10 can conunence 

19 a session with the system server (e.g., OSU CS 12) it must login by sending a 
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Login Request segment. The data that accompanies this segment includes "sn," 
which denotes the serial number of the inquiring OSU device 10, and "rc6," 
which is a random number that is to be RC6 encrypted with the Davis system 
master key and challenge. 

Type 1 - Login Response (string packet): After the server receives the login 
request from the OSU device 10, it sends a Login Response segment. The data 
accompanying this segment includes "busy," which equals T if the server is too 
busy to update the client, and "rc6." 

Type 2 - Transaction Request (string packet): This segment is used by the OSU 
device 10 to send the customer credit card and/or driver license information to the 
server. The data accompanying this segment includes "din," the driver's license 
number, "dlname," the name on the license, "dldob," the date of birth on the 
driver license, "dlexp," the expiration date of the license, "dlst," the state in which 
the license was issued, "ccn," the credit card number, and "ccexp," the credit card 
expiration date. 

Type 3 - Transaction Response (string packet): When the server receives the 
Transaction Request segment, and assuming for example that this segment 
contains credit card data, the server checks the credit card information, sends the 
request to VisaNet or other FSS 14, and sends a Transaction Response segment to 
the OSU device 10, which includes "tm," a transaction number, "time," the 
current time, which can be used automatically by the OSU device 10 to update its 
clock, and "err," an error code (optional). 

Type 4 - Transaction Commit (string packet): After the OSU device 10 receives 
the Transaction Response segment, it vends the product to the customer and sends 
the Transaction Commit segment to notify the server that the transaction has been 
committed. Data accompanying this segment includes "tm". 
Type 5 - Transaction Commit Response (string packet): The server sends the OSU 
device 10 this segment as confirmation of receipt of the Transaction Commit 
segment. If the OSU device 10 does not receive the Transaction Commit 
Response before terminating the connection to the server, it will resend the 
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1 




Transaction Commit again during the next session. No data accompanies the 




2 




sending of this segment. 




3 


• 


Tvoe 6 - Uodate Reauest fstrine oacketV The OSU device 10 nreferablv sends 




4 




this segment periodically (e.g., every 24 hours) to request configuration and 




5 




software updates. Accompanying data includes "ver," which denotes the OSU 




6 




configuration version. 




7 


• 


Tvne 7 - IJndate Resnonse rbinarv nacketV After the server receives the Uodate 




Q 

o 




RpniipQt Qp0iTipnt it checks tn ^ee if the OSU device 10 need^ to he undated and 




Q 

9 




11 oU, dCllvlO all UUVldlC IVCdUUll^w oCglllClll LfUllldllllll^ lllC/ Idlvdl V-/v-/I\. IdllJJldlwo dllVl 




10 




any other necessary OSU software. (OCR templates will be explained in a later 




1 1 




secuon oi mis spcciiicauon^. x-/very upuaic ivcbponac dcgiiicni Lundiiiuic^ d Lndin 


a 

03 


12 




of one or more update units that add, update, or remove various parts of the OSU 


i*f 




crtfih\x7S>TP* ''|"k|<*r<* cir<* civ tvi^^c nf iiTiitQ* "P'ont T Tr^Hfifp " wViif*li tpi^Isippc tViP ■fi^nl' 
oUllWdlC. IIICIC die olA LjrUCd \JL Ulllld. ITiJlll l^jJUdlw, WlllV/11 ICjJld^V^O lllC lUlll 

tpmr^latf* if it ic fllr^jjHv inQtnU^H nti tViP O^T T Hpvipp 10 nr $iHHc r^np if it Hfipcn't 

IClllUldlw 11 11 lo dllCdUy lllaldllCU Ull lllw \JiDVJ UwVlL^C IV/ \JL dUUo V./11C 11 it UV/Cdll I 


01 

Si 

u\ 


15 
16 




exist, "Font Delete," "Header Image Update," which replaces or adds header 
templates, "Header Image Delete," "Form Update," which replaces or updates the 


s|nr 
St 


17 




form template, and "Form Delete". 


O, 


18 
19 


• 


Type 8 - DEX Submit (binary packet): The OSU device uses this segment to 
periodically (e.g., every 24 hours) send DEX data to the server. 


y3 

0 






Tvnp 0 - RpQnnriQp /^ctriTiff narkpt^* TTiP ^prvpr ^piiHq thi^ ^P0fnpnt to the 


M 


21 
22 
23 




OSU device 10 to indicate that the DEX Submit segment was successfully 

received and <?aved in the database Data accomnanvinff this segment includes 
"saved," which equals ' 1 ' if the save was successful. 




24 


• 


Type 10 - Logoff Request Pay load (string packet): The OSU device 10 sends this 




25 




segment to notify the server that it wants to finish the current session. No data 




26 




accompanies the sending of this segment. 




27 




Other segments are possible, such as segments used to update product 



28 information, such as product pricing. 
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1 

2 D. Example of DMP Communication Protocol 

3 As an example of the operation of DTP, including DHP and DMP, the below table 

4 provides the data packet sequence to show how two devices (A and B, preferably OSU 

5 device 10 and OSU CS 12) login and logout using DTP. In this example, serial number 

6 for device A is 98765432 1 . 
7 



Bytes 


Protocol 


Description /Data 


A sends Login Request packet 


2 


DMP 


DMP Version 1, ACK_FLAG = 0 


0 


DMP 


Sequence Number 0 


0 


DMP 


Acknowledge Number 0 


16 


DMP 


Size of payload DMP 


16 


DHP 


DHP Version 1, Login Request Packet 


0 


DHP 


higher bite of the offload size 


0 


DHP 


middle bite of the offload size 


12 


DHP 


lower byte of the offload size 


115 


DHP 


S 


110 


DHP 


N 


61 


DHP 




57 


DHP 


9 


56 


DHP 


8 


55 


DHP 


7 


54 


DHP 


6 


53 


DHP 


5 


52 


DHP 


4 


51 


DHP 


3 


50 


DHP 


2 


49 


DHP 


1 


3 


DMP 


higher bite of the checksum 


41 


DMP 


lower bite of the checksum 


B sends Login Response packet 


3 


DMP 


DMP Version 1, ACK^FLAG = 1 


0 


DMP 


Sequence Number 0 


0 


DMP 


Acknowledge Number 0 
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Q 

Q 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 



4 


DMP 


SizeofpayloadDMP 


17 


DHP 


DHP Version 1, Login Response Packet 


0 


DHP 


higher bite of the offload size 


0 


DHP 


middle bite of the offload size 


0 


DHP 


lower byte of the offload size 


0 


DMP 


higher bite of the checksum 


24 


DMP 


lower bite of the checksum 


/I senrfi Logoff Request packet 


3 


DMP 


DMP Version 1, ACK_FLAG = 1 


1 


DMP 


Sequence Number 1 


0 


DMP 


Acknowledge Number 0 


0 


DMP 


Size of payload DMP 


0 


DMP 


higher bite of the checksum 


4 


DMP 


lower bite of the checksum 



III. Optical Character Recognition (OCR) 

As noted previously, a desirable advantage of the disclosed system is its ability to 
receive data from a consumer through optical, non-electronic means, e.g., from the 
printed text on the face of an ID card such as a driver's license. This enables the 
consumer's driver's license, in conjunction with the OSU, to operate as would a standard 
credit card containing a magnetic strip or a "smart card" containing integrated circuitry. 
This is a desirable way of obtaining consumer information, such as birth date, driver's 
license number, social security number, or the consumer's name. Indeed, when dealing 
with driver's licenses, optical analysis of the license may be the only reasonable way to 
automate information procurement, as not all states' licenses contain magnetic strips, and 
the magnetic data on the various states' licenses are encoded in differing formats. 

With this in mind, a focus of the disclosed system has been to provide an optical 
analysis algorithm capable of recognizing and analyzing the textual printing on the face 
of the driver's licenses of all fifty states. Of course, the system is not so limited, and 
could be configured to recognize other textual forms of consumer identification. An 
analysis of driver's license is disclosed merely as a preferred embodiment. 
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1 A. Background 

2 Textual data are often arranged in forms. The consistent, regular organization of 

3 a form or report makes it easy to obtain desired information very quickly. For example, 

4 the organization of a phone book makes it easy to find a specific telephone number. 

5 Other examples of forms include paycheck stubs, business cards, telephone bills, stock 

6 reports, insurance cards, credit cards, passports, visas, and driver's licenses. It is the 

7 consistency of the organization that makes the form useful. 

8 It is often the case that a transaction involves or is conditioned upon an exchange 

9 of information between buyer and seller. One example has already been given. A liquor 

10 store clerk must verify the age of the consumer prior to a transaction. The consumer's 

11 driver's license (a form) provides the necessary information. A transaction for medical 

12 services provides another example. When a consumer receives services from a doctor, 
^ 13 she shows her insurance card (a form) which provides the needed information to the 
O 14 doctor to bill the insurance company. 

|j 15 In many transactions that involve an information exchange involving a form, a 

2^ 16 human operator reads the information and either immediately acts upon it (by allowing 

17 the purchase of alcohol) or transfers the information from the customer's form (e.g., an 

s 

l^j^ 18 insurance billing number) to a computer. This can be a laborious and error prone 

0 19 process. This function is normally performed by a human operator because humans can 

H 

J] 20 read forms and computers typically can not. There is therefore a need to enable 

r 21 computers with the ability to read forms, such as driver's licenses. This section describes 

22 methods believed to be novel for doing so. One skilled in the art will recognize that these 

23 methods are easily implementable on a computer, such as those provided in the disclosed 

24 system, and could be coded in any number of ways to perform the tasks described herein. 

25 B. Template-Based Character Recognition 

26 The preferred method for optically determining the textual information printed on 

27 the face of an ID card, such as a driver's license, employs the concept of template-based 

28 character recognition. According to this scheme, one starts with an unknown character or 

29 other image, such as a letter or a picture, and compares an optically scaimed version of 

30 that character or image to a series of templates. The templates are compared to the 

31 scanned character or image to determine the extent of the "overlap" of each template. 
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1 The template with the smallest degree of overlap, i.e., the one which "lines up" with the 

2 scanned image, is chosen as the template that matches, and therefore determines, the 

3 scanned image. Of course, because the template and the scanned image may be 

4 differently centered, the template may need to be slid (e.g., up and down, and from left to 

5 right) with respect to the scanned image to ensure that the degree of overlap is accurately 

6 assessed. 

7 Template-based character recognition involves two tasks: the recognition task 

8 itself, which is discussed in this section, and the task of template creation, which is 

9 discussed in the next section. This disclosure improves upon both of these aspects of 

10 template-based character recognition, in ways that are discussed below. 

1 1 With respect to the recognition task, assume that a scanned test image, such as a 

12 scanned driver's license, contains a two-dimensional array of M by N pixels, and that 

13 D(ij) represents the intensity of a particular pixel (ij), preferably a gray scale value 

14 ranging from 0 Hex to FF Hex (i.e., from 0 to 255). Assume fiirther that there is an 

15 unknown character starting at coordinate (r,s) in the test image that represents one of K 



16 possible characters represented by K templates. (The procedure for generating the 
^ 17 templates will be disclosed later). These templates are denoted Tk(i,j), wherein k = 1, 2, . 
r ^ 18 . . K. The vertical and horizontal dimensions of the k^ template are denoted by mk and nk 
p 19 respectively. 

%|3 20 Template matching involves comparing each of the K templates to the test image 

^ 21 and choosing the template that is "closest" to the test image to determine the unknown 

22 character at (r,s). This is accomplished by calculating the least-squares "distance" 

23 between the test data D(i j) and the templates Tk(i j), which is a way of quantifying the 

24 extent of the overlap between the template and the unknown character. This distance 

25 distk(r,s), can be defined as: 

26 ^/5/,(r,5) = £ Y.(^{r + i,s^i)-T,ihj)y (eq. 1) 

1=1 j=\ 

27 For convenience, it has been assumed that M » mk and N » nk. This is a reasonable 

28 assumption because the unknown character is typically embedded in a large scanned 

29 image (e.g., several inches in both dimensions) while the size of the template is equal to 

30 the actual character size (about one tenth of an inch in both dimensions). 
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1 As noted, the metric provided by Equation 1 gives the distance between the 

2 template and the test image starting at coordinate (r,s). The template that provides the 

3 minimum distance in this equation is the "winner" and is chosen as the template that 

4 represents the character under analysis. If the character under analysis is the 

5 character, then distk(r,s) = 0; in other words, the character and the template match exactly, 

6 an ideal situation. 

7 However, in practice, the test character as scanned will probably be corrupted by 

8 noise, sampling artifacts, or other distortion. Additionally, each of the pixels of the 

9 scanned characters will preferably be represented by a gray scale value, which may have 

10 poor contrast — i.e., the image may constitute just a few shades of gray. This will cause 

11 this distance metric to be non-zero for the matching template, but hopefully small, 

12 especially in comparison to the other K-1, non-matching (incorrect) templates. However, 

13 such discrepancies can lead to errors in the recognition process, and may cause the 
□ 14 distance for a non-matching template to be smaller than the distance for the correct 
I ,5 template, resulting in an error and incorrect recognition. 

16 To relieve these problems, it has been discovered that it is desirable to vary 

^ 17 equation 1 to reduce error that might be attributed to gray scale variations as follows: 

^3 19 In this equation, fitting parameter a scales the intensity of the template while fitting 

L,^, 20 parameter p denotes a constant intensity bias. This approach is believed to be novel in 

21 that these parameters adjust the contrast of the template to match the contrast of the test 

22 data. Convenient expressions for fitting parameters a and p which result in a minimal 

23 distance can be computed using ordinary calculus: 



24 



m.n.A-BC 
a = — 



A 

QC-AB 



A 

25 where 
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/si ja\ 

/=] >1 

ffik "k 

ffljb "k 

n = Z X/)'(r+/,^+y) 

2 Therefore, the minimum distance corresponding to the optimum a and p is 

La, 3 distf^(r,s\x,^) = n-aA-pC (eq. 2) 

h 

p 4 Significant advantages are achieved through the use of this modified distance 

03 5 metric. First, in comparison to a traditional least-squares formulation, the above 

'"^rj 6 formulation only requires one pass through the data to determine the optimal a and p 

SI 

j:^ 7 using the above equations, resulting is significant computational savings. By contrast, in 

8 a traditional least squares formulation, two passes would be required to determine the 



0 9 fitting parameters a and p. In the first pass, the average value of the image data D(i j) 

^ 10 would be calculated. In the second pass, the variance of that data would be calculated. 

P 11 Because the variance calculation depends upon the average value, these two calculations 

12 must be done in sequence, and cannot be done simultaneously in one pass. 

13 Second, because this formulation, via fitting parameters a and P, adjusts the 

14 intensity levels of the template to match the test image, the intensity of a stored template 

15 is of no importance. In other words, the templates do not have to be stored with gray 

16 scale values, and can instead be more efficiently stored, such that every pixel in a 

17 template Tk(i,j) is denoted by either a logic '0' or a ' T (representing completely dark and 

18 light pixels). In other words, the templates can be stored as black and white images, 

19 without the need for storing gray scale values, typically eight bits per pixel (i.e., fi-om 0 

20 Hex to FF Hex). Additionally, "quantization" of the templates results in significant 

21 computational advantages because it turns many of the necessary multiplication steps into 
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logical operations that are more efficient. Consider for example the calculation of 
parameter "A" above, which represents the sum of products of D(r+i,s+j) and T(ij). 
Although the values for D(r+i,s+j) represent grayscale values, e.g., from 0 to 255, T(iJ) 
represent either ones or zeros. Therefore, "A" is really just the sum of all D(r+i,s+j) when 
T(ij) is equal to one. No multiplies are required, except in the calculation of "11." (Note 
that parameters "B" and "Q" depend only on the template, Tk (i j), and are computed in 
advance and stored in the template data structure for use during recognition). Some loss 
of accuracy results from this template "quantization" step. However, for images sampled 
at 400 dots-per-inch (dpi), this loss of accuracy should not lead to an intolerable error 
rate. 

As mentioned earlier, the procedure for matching a template in the vicinity of the 
test character at coordinate (r,s) is to "slide" the templates horizontally and vertically with 
respect to the test image imtil a best fit is found, preferably pixel by pixel although other 
prescribed offsets could also be used such as every other pixel. At each offset for a given 
template, the fitting parameters a and p are calculated according to the formulas given 
above, and the distance is calculated for each offset. This yields several distance 
calculations for each template, corresponding to each slide of the template, and the 
smallest of these distances is kept as the minimum distance for each template. Each of 
the minimum distances for each template are then compared to determine the template 
with the smallest minimum distance, such template being determined as the matching 
template which determines the character at (r,s). 

For larger templates, the template matching algorithms can become 
computationally demanding and a less computationally-demanding algorithm may be 
required. For this purpose, a modified distance metric can be used which only compares 
a subset of the pixels Tk(iJ) in the template with the pixels D(i j) in the test image. This 
modified distance metric is represented as 



This reduces any given distance measurement down to an assessment of P terms. The set 
of points (ip, jp) at which the distance is calculated is determined in advance and is 
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1 optimized for best performance. This procedure is called "fast" template matching and is 

2 preferably only used for large templates. These "fast" templates can be stored more 

3 efficiently than the full test image. 

4 C. Template Training 

5 To be able to optically "read" pertinent information on, for example, a driver's 

6 license, it has been discovered that it is beneficial to allow the system to "learn" the 

7 template corresponding to a driver's license of a particular state, rather than "feeding" the 

8 template into the computer in the first instance. This procedure can increase the accuracy 

9 with which optical recognition of characters on the license is determined when compared 

10 v^th pre-fed templates, which may or may not accurately reflect the true structure of the 

11 "form," and which may not be able to handle variations in the elements on the license. 

12 However, while this training approach is believed novel, template training is not 

13 specifically necessary to the implementation of the disclosed invention, and pre-fed 
P 14 templates (i.e., templates generated off-line and in advance of recognition) may work 

rjl 15 adequately. 

SI 

qi^ 16 Template training involves using example characters to generate a character 

4' 17 template T(i,j). Throughout the training process, it is assumed that a set of scanned forms 

B 

M, 18 is available. For example, if the problem presented is character recognition for a Texas 

T\ 19 driver's license, then we will assume that several, e.g., 30, different Texas driver's 

'4^ 20 licenses have been scanned into the computer. This driver's license image data will be 

P, 21 used during the training process. During template training, the driver's license data will 

22 be used to obtain examples of each character. For example, if we wanted to create a 

23 template for the character "5," we would look through the inventory of 30 scanned Texas 

24 drivers licenses and extract all the examples of the character "5" to form the template. 

25 Note that an operator must review the scanned license to isolate those portions of the 

26 larger image that contain the image for the number "5" in order to provide the examples 

27 necessary to "train" the "5" template. This is a time consvmiing process which can be 

28 automated somewhat by a computer or workstation. 

29 As the generation of only a single template is referred to, the index ("k") has been 

30 dropped fi*om the notation. Let Ai(ij), AiOJ), . . . AN(iJ) represent examples of a 

31 particular character isolated fi-om the set of sample licenses. The template T(iJ) will 
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1 preferably recognize all of the given examples as if they were actually embedded in a test 

2 image. Therefore, the template is chosen to minimize the distance between the template 

3 and each of the examples. Due to uncertainty in the sampling phase and other anomalies, 

4 the examples must be shifted imtil they are all aligned. The total error or distance 

5 between the template and the examples is expressly mathematically as 

A=l /=! y=l 

7 The offsets (rk,Sk) are adjusted until a minimum of the total error is reached. At the 

8 minimum, the template is given by the average of all the examples, which is expressed 

9 mathematically as 



10 



p 11 This formula can be updated recursively as new examples are found. Thus, suppose 

O 12 AN(ij) represents a new example. When this new example is shifted until a best fit (i.e., 

03 

13 minimum distance) is achieved, a new offset (rN,SN) is provided. The template formula 

'^l 14 can then be updated as follows: 

"•■^ N 1 1 

r 15 T{i,j) = -^T{i,j)-\r—A^{r^-^i,s^-^j) 

U N N 

O 16 D. Sequence Estimation 

17 Information in a form is typically represented by more than just a single character. 

£3 18 The information of interest may be a date, a number or amount, a word, a name, etc. 

19 These types of information are represented by a sequence of characters. A sequence 

20 estimation algorithm uses the character recognition algorithm of the previous sections to 

21 recognize the individual characters of a word, number, or other string of characters. The 

22 sequence estimation algorithm must also be able to detect the end of a variable length 

23 string of characters. 

24 Sequence estimation takes as its input a pattem specification. The pattern 

25 specification defines specific characters, or more generally types of characters, that are 

26 present in a string of characters. Various different characters include numbers, capital 

27 letters, lower-case letters, punctuation, delimiters, and symbols. Character types include 

28 "wild cards" (designating any particular character), letter type (whether upper or lower 
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1 case), and alphanumeric type (any letter or number). Character types may also include 

2 other symbols, for example, the seal appearing on a driver's license. A pattern 

3 specification also contains information on the minimum and maximum niunber of 

4 characters that can occur within a particular test image. 

5 Take for example the birth date on a Texas driver's license, which takes the 

6 following format: MM-DD-YY, where MM represents the month, DD represents the day, 

7 and YY represents a year, and where each of these designator is separated by a dash 

8 In this format, both the month and the day may be either one or two characters in length 

9 (compare 9-1-75 with 11-12-75). Thus, a pattern specification for the date would look 

10 like 

11 N[1:2]"-"NI1:2]"-"N[2:2] 

12 The "N" denotes that the particular field contains numbers, and [1 :2] denotes a sequence 
^ 13 with either one or two characters. Together, N[l:2] denotes that the computer should 
Q 14 look for a variable length sequence of numbers of either one or two characters in length 

15 (the month). Continuing through the pattem specification, the computer next looks for 

16 one dash character followed by another variable length sequence of nimibers of either 
4^ 17 one or two characters in length (the day), followed by yet another dash. Finally, the 

a 

l^ji, 18 computer looks for the last sequence, which necessarily constitutes a two-character 

^ 19 numerical sequence (the year). This exemplary pattem specification consists of five 

yjj 20 elements, referred to as pattem characters, although two of these pattem characters 

^ 21 (N[l :2] and "d") are repeated for this particular pattem specification. 

22 Consider as another example the consumer's name as printed on the face of Texas 

23 driver's license, and assume that the name is written in all capital letters with the first 

24 name first and the last name last. A suitable pattem specification should be able to 

25 describe the name "ALEXANDER PEABODY" as well as "JON DOE," even though 

26 these names are different in length. Such a pattem specification might look like 

27 A[l:641 " " AI1:64] 

28 Here, the "A" designates a capital letter. So, this pattem tells the computer to look for 

29 between one and sixty-four capital letters in the first name, followed by a space, followed 

30 by between one and sixty-four capital letters in the last name. Again, this pattem 

31 specification consists of three pattem characters. 
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1 If lower case letters were used then the letter "a" could be used to designate the 

2 lower case alphabetic character type. Thus, if a name were printed using capital letters 

3 for only the first letter of each name, and if the last name were printed first and separated 

4 from the first name by a conmia and a space (e.g., "Lewis, Terril"), a suitable pattern 

5 specification might look like 

6 AI1:11 a[l:63] V " " A[l:l] a[l:631 

7 As noted earlier, the sequence estimation algorithm uses the pattem specification 

8 to determine what sets of templates to use when performing character recognition. 

9 Therefore, in the last given example above, sequence estimation will utilize 54 different 

10 templates to assess the consumer's name: 26 Texas license "capital letter" templates, 26 

11 Texas license "lower case letter" templates, and Texas license templates designating the 

12 comma and space. For this example, the pattem specification contains four pattem 

^ 13 characters. 

p 

□ 14 There are two methods for sequence estimation: maximum likelihood sequence 

53 

g«} 15 estimation (MLSE) and symbol by symbol detection. MLSE essentially builds a tree of 

2^ 16 all possible patterns allowed by the pattem specification. Every combined pattem is tried 

4Z 17 and the best matching pattem is the winner. Performing this comprehensive search is 

1^^^ 18 time consuming but can be efficiently implemented in a given application if necessary, 
p 19 As an example of MLSE, suppose the computer is provided a pattem specification 

4^ 20 "N[2:3]," denoting the analysis of a sequence of numbers that is either two or three 

21 nimibers long. There are 1100 different sequences that fit this specification: 00, 01, 

22 09, 10, 11, 19, 99 (i.e., 100 two-number sequences), and 000, 001, 009, 010, 

23 Oil, 019, 099, 100, 101, 999 (i.e., 1000 three-number sequences). In MLSE, 

24 the computer would concatenate together the image templates for each of these 1 1 00 

25 sequences, would compare each of these concatenated templates with the single test 

26 images of the characters imder analysis, and would choose the one with the best match 

27 using the template matching algorithm disclosed above. In each case, the whole 

28 sequence of characters is compared as if it were one image as opposed to comparison of 

29 the individual characters. 

30 While not as comprehensive, symbol by symbol detection generally performs as 

31 well as does MLSE when the distortion in the given image is low, which is usually the 
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1 case in form processing, and therefore is the preferred approach employed by the OSU. 

2 In symbol by symbol detection, character recognition proceeds in a linear sequential 

3 fashion through the character string under analysis. Consider again the pattern 

4 specification of N[2:3]. Employing symbol by symbol detection, the computer would 

5 look at the specification and would see that the first character must be a number. The 

6 computer would perform template matching, as disclosed above, using the templates for 

7 the characters 0 through 9, and choose the best match. Suppose that the best matching 

8 template for the first character was "5". The computer would then again consult the 

9 specification and see that the next character must also be a number. It would therefore 

10 again perform template matching and choose the best match. Suppose that the best 

11 matching template for the second character was "4," so that, thus far, the sequence "54" 

12 has been recognized. Next the computer would look at the specification and see that the 
g 13 next character may be a number, but may also be a space (" ") because the specification 
□ 14 indicates that the sequence may be either two or three numbers in length. Accordingly, 
m 15 when performing pattem matching, the computer consults the templates for 0 through 9, 



16 and additionally consults a space template (which would be a blank template). Suppose 



^ 17 that the best matching character was " Then the computer ultimately determine that the 

^ 18 sequence under analysis was "54". Suppose, on the other hand, that the best matching 

C3 19 character was "3". Then the computer would ultimately determine that the sequence 

20 under analysis was "543." 
2 21 Representing a particular element pursuant to a pattem specification is beneficial 

22 in that it reduces the number of character (or symbol) template comparisons that need to 

23 be used in the analysis of a given element. Take, for example, the "lastname, firstname" 

24 pattem specification of A[l : 1] a[l :63] " " A[l : 1] a[l :63] discussed earlier. As noted, 

25 this pattem specification requires the use of 54 templates to perform an analysis of the 

26 alphabetical string "lastname, firstname". Were a pattem specification not used to assist 

27 in the analysis, each character in the name imder analysis would potentially need to be 

28 compared against each of the 54 templates. For even a short name, like "Li, Tan", 

29 consisting of five letters, a space, and a comma, this exercise could involve 54 * 7 

30 template comparisons, which could be very computationally demanding and slow. By 

31 providing the algorithm, through the pattem specification, information concerning the 
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1 expected characters in the element, the number of comparisons is greatly reduced. For 

2 example, determination of the first letter in the name requires comparison to only 26 

3 templates, i.e., the upper case templates, and the sequence estimation algorithm may 

4 ignore the lower case letter templates, the space template, and the dash template. By the 

5 time the analysis is completed for this example, the number of comparisons is 

6 approximately cut in half This results because the pattem specification references only a 

7 particular subset of templates to be used at certain points in the analysis. 

8 E. Form Decomposition 

9 Although the disclosed character recognition techniques may be used with a 

10 variety of forms, a driver's license is used as the example form in the following 

1 1 discussion due to its utility in the disclosed Davis system. 

12 As shown in Figure 8, a driver's license contains many different pieces of 
^ 13 information, including: the license (form) header 50, which identifies the state in which 
P 14 the license was issued (e.g., "Texas"), (2) data 52, such as the holder's name, address, 

^ 15 date of birth, driver's license number, and expiration date, (3) a holder ID photo 54, and 

SI 

Jl 16 (4) a validation seal 56, used to verify the genuineness of the license. For a particular 

% 17 state, the Mormation is arranged on the card at various kno,™ locations. The date of 

^ 18 birth, for example, is always located in the same general vicinity on a Texas driver's 

19 license. 



20 To process the driver's license, the license is decomposed into three hierarchical 

21 levels, called "form," "cluster," and "element." An element 58 denotes a single piece of 

22 information, such as the date of birth. A cluster 60 denotes a group of elements, or 

23 possibly a single element, that occur near each other on the license. For example, the 

24 license class, the date of birth (DOB), the expiration date, license restrictions (REST), 

25 and "END", may all represent elements 58 within a single cluster 60. A form 62 denotes 

26 a group of clusters, and typically represents the entire image under analysis. 

27 The form and each cluster typically have "headers" with which they are 

28 associated. For example, form header 50 on the Texas driver's license reads as 

29 "TEXAS." Several pieces of graphical information within cluster 60 could operate as 

30 cluster header 61, such as "CLASS:", "DOB:," or even possibly the graphic of the Texas 

31 flag above these elements, were this graphic to be contained within cluster 60. For 
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1 simplicity, and unless otherwise noted, it will be assumed that "DOB:" operates as the 

2 cluster header 61 for the cluster 60 illustrated in Figure 8. 

3 The form header and the cluster headers contain, respectively, a form header 

4 origin and cluster header origins. The form header origin 63 and the cluster header 

5 origins (e.g., 65) are represented, respectively and preferably, by the upper-left-most 

6 pixel in the form header and the given cluster header. The form header origin is 

7 determined with reference to the upper-left most pixel in the entire scanned image, which 

8 is referred to for convenience as the image origin 67. Thus, if the image origin has 

9 horizontal and vertical coordinates of (0,0), and if, for example, the entire image is 1000 

10 pixels in the horizontal direction and 768 pixels in the vertical direction, the form header 

11 origin 63 for the form header 50 in the exemplary Texas driver's license shown in Figure 

12 8 might be approximately (400,20). 

13 The cluster header origins are determined with respect to form header origin. In 
£3 14 this respect, once the form header origin is known, that origin operates as the "master" 

15 origin from which the clusters are located. Relating the cluster header origins to the form 

2I 16 header origin, as opposed to the image origin, assists in the subsequent optical analysis of 

yl 

=|2 17 the clusters in the event that the printing on the license has been uniformly shifted in a 



5 



u ^8 given direction. Thus, if the form header origin 63 is "reset" to (0*,0*), the cluster 

J«3 19 header origin 65 for the "date of birth" cluster might be at approximately (-350*,! 80*) 

20 with respect thereto, or approximately (50,200) with respect to the image origin. Of 

21 course, in a given application, the image origin can be used as the reference point for 

22 location of both the form header origin and the cluster header origins. 

23 The location of each element, as defined by element origin 69, can be known with 

24 reasonable precision within a given cluster, and is determined with reference to the 

25 cluster header origin. An analysis of driver's licenses shows that there is a high 

26 variability (plus or minus 15 pixels) in the position of clusters relative to the form header 

27 origin but very small variability (plus or minus 1 pixel) in the position of elements 

28 relative to its cluster header origin. This provides the motivation for decomposing the 

29 form as described above. 
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1 

2 F. Template Training in Practice And Exemplary File Structures 

3 Figures 9A and 9B show a simplified illustration of the organization of the 

4 various computer files or data structures that are used by the disclosed OCR algorithms 

5 and a description of their contents. One skilled in the art will recognize that the files 

6 necessary for OCR as disclosed herein could be organized and structured in numerous 

7 ways. Indeed, Figure 10 represents a broader disclosure of the organization of the data 

8 structures as they are preferably applied in a commercial system. Figures 9A and 9B are 

9 thus merely illustrative to describe possible relations between the various data structures 

10 referred to in the foregoing paragraphs in this section. 

11 Referring to Figures 9A and 9B, a file, called information file 400, contains the 

12 basic structure for the analysis of a particular drivers license form. File 400 is in this 
U 13 embodiment split into two sections that comprises the form and cluster information files 
C3 14 402 (see Figure 9A) and the font information files 404 (see Figure 9B) for a particular 
Ql 15 license. In a preferred embodiment, each state would have entries in both of files 402 and 

16 404, although only the state of Texas is shown as an example. 
^ 17 Generally speaking, form and cluster information file 402 contains information 

L,i, 18 used in processing a particular form, such as the form name, the name of the file 

pa 

'7" 19 containing the form header template, and the form header origin. Form information file 

4} 20 402 also contains information concerning the various clusters of interest in the form, such 

O 

1^ 21 the cluster name, the names of the file containing the cluster header template, the cluster 

22 header origin, the element origin for each element in the cluster, the pattern specification 

23 for each element, and the font associated with each element. Optionally, file 402 may 

24 also contain information such as the sizes of the form header and the cluster header 

25 specified relative to the form header origin and the cluster header origin respectively. For 

26 example, if it is known that the form header is 300 pixels in the horizontal direction and 

27 80 pixels in the vertical direction relative to the form header origin, these offset may also 

28 be specified in file 402, and may be of assistance in further defining the location of the 

29 form header in the image under analysis. 

30 Generally speaking, font information file 404 contains all of the necessary font 

31 information for a particular form. What fonts are required for a particular form is 
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1 determined by the pattern specifications specified in the corresponding form and cluster 

2 information file 402. Thus, in the simple example shown in Figures 9A and 9B, which 

3 contains the file structures necessary for determining the date of birth and expiration date 

4 on a Texas driver's license, the font information file 404 contains information concerning 

5 the fonts necessary to implement the pattern specification for these elements. In this 

6 case, the same pattem specification, N[l:2] N[l;2] N[2:2], is used to decipher 

7 both the date of birth and the expiration date because both of these elements on a Texas 

8 driver's license have the same format. However, for exemplary purposes, assume the 

9 date of birth is written in courier 12 point font, while the expiration date is written in 

10 courier italic 12 point font. Both of these font types are specified for each element, as 

1 1 shown in Figure 9A. 

12 As noted, both the form and cluster information file 402 and the font information 

13 file 404 specify and reference certain template file names, which are respectively referred 
Q 14 to as form and cluster templates files 406 and character templates files 408. Form and 
Q1 15 cluster template files 406 contain the form header template and the cluster header 

16 templates for a given state. Thus, and for example, the Texas form and cluster template 

=P 17 files in Figure 9 include the form header template (e.g., "Texas"), which as previously 

s 

^ 18 noted is the first template that will be considered when determining the state 

F'^ 19 corresponding to the license under analysis. Also included are the cluster header 

y3 20 template files. In this example, "DOB:" is used as the cluster header, although other 

□ 

1^ 21 headers within this cluster could be used as well, such as "CLASS:" or even a graphic 

22 such as the picture of the Texas flag (see Figure 8). Of course, and depending on the 

23 information desired from the license, other headers may exist for a particular license 

24 form. 

25 Font templates files 408 include all of the necessary character templates 

26 referenced by the pattem specification during sequence estimation. Thus, for the date of 

27 birth pattem specification, which references Font 1, a total of eleven templates are used, 

28 each written in Courier 12 point font as specified. Thus, ten of these templates 

29 correspond to font name N, which constitutes (preferably learned) templates for the 

30 numbers 0, 1, 2, ... 9 as they appear in the date of birth field on a Texas drivers license. 

31 Together these 10 templates constitute a character template family. The eleventh 
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1 template corresponds to font name dash and is the template for the dash that separates 

2 the month, day, and year. Because, as assumed, the expiration date is written in Courier 

3 italic 12 point font, referencing Font 2, a different set of eleven templates are referenced, 

4 and which correspond to italicized versions of the eleven templates referenced with 

5 respect to the analysis of date of birth. 

6 Of course, other fonts and character templates may be required for a given 

7 application. Additionally, and as mentioned earlier, letter fonts may be required for word 

8 or name analysis, such as capital letters and lower case letters, and which are designated 

9 respectively by "A" and "a" in the pattern specification. In this case, the font template 

10 file 408 would additionally contain 52 template files, corresponding to the 26 capital and 

11 lower case letters, for both the italics and non-italic Courier fonts. Further, each license 

12 form will probably require its own unique font templates, as it is unlikely that the fonts 
q 13 used between two different state's licenses will be suitably similar for analysis purposes, 
g3 14 although this is possible. 

01 15 Of course, an operative embodiment need not structure the files in the exact 

g=j 16 manner specified in Figures 9A and 9B. For example, the form header origin, or the size 

4' 17 of the form header template, could be stored in file 404 instead of in 402. Furthermore, 



18 the form and cluster information file 402 could be hierarchically split into two separate 

Q 



Q 

■ 19 form header and cluster files. Other variations are possible, as one skilled in the art will 



€J 20 immediately recognize. 

[pi, 21 A suitable file structure such as that shown in Figures 9A and 9B must be set up 

22 in advance of analyzing a particular license. This preferably requires template training 

23 and other manual and computer-assisted analysis of the example licenses. Thus, the form 

24 header 50 and cluster headers 61 are preferably trained as discussed above, and their 

25 origins 63 and 65 (and, if necessary, sizes) determined. Element origins with a particular 

26 cluster must also be determined. Additionally, the font templates for the elements are 

27 preferably trained, again as discussed above. Finally, the pattern specification is 

28 determined. Such training is preferably formed on each state's license to be analyzed, 

29 again using preferably at least a minimum of thirty exemplary licenses. With such 

30 information pulled fi"om the exemplary driver's licenses, files may then be structured and 
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1 linked as shown in Figure 9, (or more preferably, as in Figure 10), and analysis of a 

2 license may now begin. 

3 G. Form Processing 

4 Form processing begins by taking a test image of the form under analysis, 

5 preferably by scanning with the OSU 6, wherein each pixel of the test image is associated 

6 with a black-and-white (grayscale) intensity (i.e., D(ij)). (Color information could also 

7 be stored, but is not expected to be necessary for the analysis of driver's licenses. If color 

8 information is desired, the lamps 218 in the OSU 6 would preferably be modified to 

9 illuminate the license in red, blue, and green light, as one skilled in the art would 

10 recognize.) This image is preferably initially stored in the SRAM memory 234 on the 

11 OSU 6, and processed locally using the necessary template information stored in Flash 

12 232. 

p 13 The first step in the analysis is to determine the state of the license at issue. In 

P 14 this regard, each state's header template file is compared to the relevant pixels on the test 

15 images, using the stored form header origin to determine the suspected location of the 

^ 16 header. Therefore, when attempting to match the Texas header template, the form header 

=P 17 origin (e.g., 400,20) specified in file 402 is located in the test image, and the characters 

Li 18 present at that position on the image are template matched. Because the form headers 

19 (e.g., "Texas") are typically printed in a large type face on the license, the "fast" template 

^3 20 matching technique disclosed earlier preferably used for identifying the license type, 

O 

^ 21 Additionally, if information about the size of the form header has been stored in the form 

22 and cluster information file 402 as well as the form header origin, a particular rectangular 

23 field of pixels on the test image may be extracted, which may quicken analysis and better 

24 define the pixels on the test image to be analyzed. 

25 Once the license type is determined and a template is chosen (e.g., the Texas 

26 template), cluster processing begins on each cluster of interest. For example, if it is 

27 desired to extract only the date of birth fi-om a Texas driver's license, which would be 

28 necessary in an application requiring age verification, then there is only one cluster 60 to 

29 process. In this example, the cluster header origin is read fi'om file 402, which as noted 

30 earlier corresponds to a pixel offset (x*,y*) with respect to the form header origin. 

31 However, because the location of the cluster may vary by plus-or-minus 15 pixels, the 
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1 cluster header template 61 is preferably "slid" horizontally and vertically within this 

2 variable range to locate and "set" the cluster origin 65 as a particular pixel on the test 

3 image. This sliding and setting process involves assessment of the minimal distance as 

4 discussed above. 

5 The analysis would be more complicated, and perhaps more time consuming, for 

6 an assessment of clusters that did not contain a cluster header, which would be the case if, 

7 for example, it was desirable to determine the name of the consumer from the face of the 

8 license. In this case, the cluster template would still have a pre-determined cluster origin, 

9 but would lack information about content. In this case, sequence estimation would begin 

10 immediately at the location of the cluster origin. Otherwise, a black rectangle the size of 

11 one capital letter could be used as a dummy cluster header template to assist in 

12 determining the location of the cluster or the elements within it. 

Is-!. 

pi. 13 Once the cluster header origin (or more generally, the cluster origin) has been 

Q 14 determined, sequence estimation is performed for each element in the cluster as described 

03 

15 above. The first step is to apply the element origin provided in file 402 to determme the 

16 location of the elements and the pixels at which sequence estimation analysis should 

Of 

=|S 17 begin. As noted previously, because the locations of the elements are known very 

l^j^ 18 precisely relative to the cluster origin (usually plus or minus one pixel), sequence 

19 estimation preferably begins immediately at this point without the need for template 

a3 20 shifting and distance determinations. However, these extra steps may be useful in a given 

21 application to further ensure the accuracy of the analysis. Thereafter, the pattern 

22 specification (e.g., N[l :2] N[l :2] N[2:2]) is retrieved from file 402. Each portion 

23 of the pattern specification is linked to a font name in file 404, which in turn specifies the 

24 requisite character template files in file 408. These character template files in file 408 

25 may then be used during sequence estimation as discussed above to determine the textual 

26 content of the element under analysis, in this case, the date of birth. As mentioned 

27 earlier, the templates consulted by the sequence estimation algorithm are preferably 

28 binary templates, which provides for efficient use of memory in the system and which 

29 speeds up the analysis. 
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# 



1 

2 H. Form Validation 

3 As noted above, the test image of the driver's license is an optical image of the 

4 license that has been converted to grayscale. However, it might be easy to tamper with 

5 the license, e.g., by changing the date of birth with a marker, to fool the system. Or, a 

6 completely false form might be generated, e.g., using a computer and a printer. For this 

7 reason, it is preferred that a commercial system employ further analysis measures to 

8 verify the validity of the form being analyzed. 

9 Several different methods of validation are possible. For example, most states' 

10 driver's licenses use a seal or hologram somewhere on the face of the license that can 

11 also be detected and analyzed using character recognition techniques. (The hologram can 

12 be detected as it will cast a shadow upon optical illimiination within the OSU). This is 

13 preferably performed by training a template to represent the seal or hologram. 

£3 14 Recognition of the seal or holographic image after recognizing the date of birth provides 

03 

g^l 15 the needed verification, and helps to ensure that the form under analysis is not wholly 

gij 16 false. For identification forms having a bar code, templates of the bar codes could also be 

•I* 17 stored and optically compared with the bar code on the form to further verify form 

s 

18 validity using the disclosed techniques, which might be simpler in some applications than 

H 19 actually reading and interpreting the bar code in the standard maimers known in the prior 

y3 20 art. 

Q 

21 Additional validation measures can be accomplished by comparing OCR data 

22 with magnetic stripe data. In this case, the OSU would also be fitted with a magnetic 

23 head, as in OSU 6, and the system configured to compare the optical data and the 

24 magnetic data to compare the retrieved information to ensure that tampering has not 

25 occurred. Further security could be added by encrypting the magnetic data. Of course, 

26 such a scheme would not be possible if the license under analysis does not contain a 

27 magnetic stripe, which is the situation in some states. Additionally, validation could be 

28 compared through a comparison of optical data with the consumer's credit card data to 

29 compare, for example, the consimier's name. 

30 In the future, other types of verification may be used with licenses that could 

31 provide higher levels of security, and which could be easily handled with the disclosed 
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1 techniques. For example, in the future, images could be encoded in the license which are 

2 only visible using an infrared detector. Such a security measure would be difficult to 

3 forge. If the OSU were fitted with an infra-red light source and detector, validation of the 

4 license could be performed with great confidence that the license is authentic and has not 

5 been tampered with. 

6 I. Handling of ID Cards Not Yet Having a Template on the System 

7 It would be expected in a commercial system that a consumer may try to enter an 

8 ID card for which a template has not yet been created and stored in the system. In this 

9 instance, it is presently preferred that the ID card be scanned by the system, saved, e.g., in 

10 database 70, and that the following message be displayed to the consumer: 

11 "The ID card you have inserted is not currently supported by the Davis 

12 system at this time. However, if you return within X hours, our system 

13 administrators will try to ensure that your ID card vsdll be useable in the 

14 system. Please wait a few seconds while we scan your ID card. Thank 

15 you for your patience. We look forwarding to approving your ID card 



S 16 Within X hours." 

SJ 18 During the X hour timeframe, the system administrator will ideally have time to assess 

J. 19 the stored image and create a template for it recognizable by the system. Otherwise, the 

f 20 image itself could be used as a specialized template, with systems assistants during this 

Q 21 time working offline to verify the information on the card with appropriate officials, and 

J^J 22 then storing the contents of the ID card in a specialized file in the system associated with 

C3 23 that specialized template. Thereafter, when the consumer retums to the system, his ID 

24 card will be recognized, but not necessarily subjected to analysis using a pattern 

25 specification. Instead, the ID card would be template matched, and information for that 

26 specialized template would be pulled from the specialized file created for that ID card 

27 and verified accordingly. 

28 

29 IV. System Configuration 

30 A. Arrangement of Data Structures In The Database 

31 Periodically, it may be necessary to provide updates usable by the OSU devices 

32 10 in the Davis system. For example, in a system placed in service on a nationwide scale, 

33 and capable of receiving several different driver's licenses, the system's templates may 
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need to be periodically updated if a given state changes the structure of its license. 
Additionally, it may be possible to add new functionality to preexisting OSU devices 10. 
Thus, an OSU device initially structured as a vending machine could be updated to also 
act as a change machine, or may be modified to allow age verified vending. Likewise, 
the OSU devices 10 may have to report data to the system. Such data can take many 
forms and could constitute, for example, the sending of the image data taken from the 
license or provide information relevant to the servicing of the OSU device 10. 

Figure 1 1 shows a subset of the larger Davis system 8 and explains the way in 
which the central components in the system are managed. This figure shows an OSU 
device 10, the OSU connection server(s) 12 (OSU CS 12), the server cluster 18, and the 
management console 22. In this figure, the OSU CS 12 and the server cluster 18 are 
combined into one logical block in recognition of the similarity in function that these two 
components may provide. This combination in Figure 1 1 notwithstanding, in a preferred 
embodiment, the OSU CSs 12 preferably merely act as communication points for the 
OSU devices 10, while the server cluster 18 stores important system data (such as 
consimier files and template files), performs necessary computations and interfaces with 
other non-OSU systems (such as user interface 20, FSS 14 or other integrated systems 
24). Of course, one skilled in the art will recognize that these fiinctions could be split 
between the servers 12 and 18 in any number of ways. 

Important system data is preferably stored in database 70, including the 
configuration data for each OSU device 10 present on the system. The configuration of 
the various data components necessary to run the system and which are preferably stored 
in database 70 are shown in Figure 10. Figure 10 illustrates the various data tables and 
files (more generally, data structures) that are stored in the database, and shows their 
relationships in an "Entity Relationship Diagram" (ERD) format that is well known to 
those of skill in the art of database architectures. Pursuant to this format, the various 
tables within database 70 have relationships structured in a one-to-one (1-1) format, a 
one-to-many (1-m) format, or a many-to-many (m-m) format. Of course, the database 
could be structured in a variety of different ways to achieve suitable system performance 
as disclosed herein. Thus, Figure 10 is merely exemplary of a commercial embodiment. 
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The contents of each table in Figure 10 are described in the following paragraphs. 
It is important to note that the database structure supports more than one version of a 
template. For example, the state of Texas may have three different versions of its 
driver's license that have been issued and are active, and the system should be able to 
comprehend all three types. Accordingly, the system stores various versions of the 
templates and other supporting information relevant to the version, as shown in the 
disclosed "[Name]_version" tables below. 

Consider, for example, tables "Header'' and "Header_version" below. The 
"Header" table has only a few fields, including header name, description, and status. By 
contrast, the "Header_version" table contains a significant number of fields that apply to 
OCR analysis, including the form header templates that are used during OCR analysis. If 
an ID card authority like the State of Texas decides to issue a new license, a new form 
header version record is created and updated with the latest information. Such an 
organization scheme is similar to assigning a new model number to a product when just a 
few features in the product have been changed. In short, through this organizational 
scheme, a catalog of all versions of licenses issued in the State of Texas can be 
maintained and referenced in the database. 

• Geo: The "Geo" table stores information about the geographical locations of 
OSU device 10. 



Geo 


Name 


Type 


Description 


Id 


String 


Unique identifier for every geo record 


Name 


String 


Name of the geographical location 


Note 


String 


Description of the geographical location 


Creatorid 


String 


The user id that created this record 


Editorjd 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if the record is active or not 



21 
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Osu: The "Osu" table represents information for a particular OSU device 10. 



Q 

m 
m 



Osu 








Id 


String 


T Jniniie iHentifier fnr everv OQii record 




^trina 


O^ii rnnfiQ id that Hnk^ this nsii recnrH to its conficniration record in 

osu config table 


Serial no 


String 


Osu unit serial number 


Time zone 


String 


Time zone for the osu unit 


Line] 


String 


Address line 1 for the osu unit 


Line2 


String 


Address line 2 for the osu unit 


Pitv 


on Ulg 


r^itv in whiph r»Qii ic lr*P5*tpH 
111 wiiiwi Uou lo ii^waicLi 


State 


String 


State in which osu is present 


Zj\p 


oinng 


Ziip cooe or uie osu locaiion 


Directions 


String 


Directions if any to get to that osu unit 


Cert 


String 


Certification of osu unit 


Creator_id 


String 


The user id that created this record 


Editorjd 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if the record is active or not 


Acquirer_bin 


Integer 


Visa assigned Bank Identification number issued by the merchant's 
member bank or processor 


Merchant_number 


Integer 


A unique number assigned by the signing merchant s bank or 
processor used to identify the merchant within the VisaNet system. 


Store_nuniber 


Integer 


Number assigned by the signing member, processor to identify a 
specific merchant store within the VisaNet system 


Terminal_number 


Integer 


Number assigned to identify a unique terminal within a merchant 
location 


Devicecode 


Character 


Device type of the merchant submitting the authorization request 


Industrycode 


Character 


Industry type of the merchant submitting the authorization request 


Language 


String 


Language to be used in formatting the authorization response text 
message 


Merchant_category 


Character 


Number assigned by the signing member or processor to identify a 
merchant industry classification 


Merchant_name 


String 


Merchant Name 
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• Osu_config: This table contains configuration information for each OSU device 
10. It has 1-m relation with "Osu" so that a single configuration can be applied to 
multiple OSU devices 10. "Osu_config" is linked with "Ocr_form " "Header" and 
"Ocr_font_set," and is related to each with a m-m relation. As will be explained later, 
each of these three tables is associated with a corresponding version table. At one time, 
only one version of each will be active for a particular configurable OSU device 10. 



Osujconflg 


Name 


Type 


Description 


Id 


String 


Unique identifier for every osu record 


Name 


String 


Name of the osu configuration 


Version 


Integer 


Version of the osu configuration 


Creatorjd 


String 


The user id that created this record 


Editorjd 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if the record is active or not 



• Header: This table contains information about the various form headers, and has 
a 1-m relation vsdth "Header_version" table. 



Header 


Name 


Type 


Description 


Id 


String 


Unique identifier for every header record 


Name 


String 


Name of the header 


Description 


String 


Description of the header 


Status 


Integer 


Status of header record to indicate if this header is the current 
(indicated by 0), added (indicated by 1) or removed (indicated 
by 2) one from the configuration 
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• Header_version: This table provides information for the headers, like their form 
header origin coordinates, and possibly their bottom right coordinates. It also stores 
multiple versions of the form header templates for the relevant states. 



Header version 


Name 


Type 


Description 


Id 


String 


Unique identifier for every header version record 


Template_packagejd 


String 


Template package record id that this header version is a part of 


Headerjd 


String 


Header record id which it is a version of 


Version 


Integer 


Version number of this header version 


Imagename 


String 


Image name used by this header version record 


Topleftid 


String 


Top left comer of the header region structure 


Rightbottomjd 


String 


Right bottom comer of the header region structure 


Creator_id 


String 


The user id that created this record 


Editorjd 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Header__template 


Binary 


Scanned image of the header version 


Active 


String 


Flag representing if this version is active for its parent header 



• Ocr_font_set: As mentioned previously, elements in a given form can be written 
using various fonts, such as Courier font, and these may be printed in different sizes. 
Basic font information for the elements is provided in the "Ocr_font_set" table. This 
table has 1-m relation with the "Ocr font set version" table. 



Ocr Jdni_set 


Name 


Type 


Description 


Id 


String 


Unique identifier for every font set record 


Name 


String 


Name of the Ocr Font Set 


Description 


String 


Description if any, for the font set 


Status 


Integer 


Status of font set record to indicate if this font set is the current (indicated 
by 0), added (indicated by 1) or removed (indicated by 2) one fix)m the 
configuration 



• Ocr_font_set_version: This table is dependent on "Ocr_font_set" and provides 
information for any "Ocr__font_set." The basic information for each of the fonts is stored 
within this table. Thus, "Family" represents the basic font type (e.g., Arial or Courier), 
"Font_size" represents the size of the font (e.g., 10 point or 12 point), and "Style" 
represents modifications of the font, such as italicized or bolded. It has 1-m relation with 
"Font_type" table. 
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Ocr Jbntsei_version 


Name 


Type 


Description 


Id 


String 


Unique identifier for every font set version record 


Template_packagejd 


String 


Template package record id that this font set version is a part of 


Ocr_font_set_id 


String 


Font set record id which it is a version of 


Version 


Integer 


Version number of this font set version 


Family 


String 


Family of the font set (e.g., Arial or Courier) 


Font__size 


String 


Size of the font set (e.g., 10 point or 12 point) 


Style 


String 


Style of the font set (e.g., bold or italic) 


Creator Jd 


String 


The user id that created this record 


Editorjd 


String 


The user id diat edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if this version is active for its parent font set 



• Font_type: This table stores the various types of characters recognizable by the 
system, such as "A" for upper case letters A-Z, "a" for lov^er case letters a-z, "N" for 
numbers 0-9, "P" for punctuation and symbols (such as .;"-/;:!?()[]{}%$), "Z" for any 
upper or lower case letter, "X" for any letter or number, for a wildcard representing 
any character, and "S" for a space. It has a 1-m relation with "Fontjattem" table. 



Fontjype 


Name 


Type 


Description 


Id 


String 


Unique identifier for every font type record 


Ocr_font_set_versionJd 


String 


Font set version record id which it is a type of 


Fonttype 


String 


Specifies the type of character stored in the associated font type 
(e.g.,"A,'"V"N," "P;'etc.) 


Description 


String 


Description of the character that font type has 



• Font_pattem: This table stores the character templates for a given font. For 
example, there would be twenty six templates stored within the "Font_pattem" table for 
each upper case letter and for each font type. Thus, assuming two fonts (e.g., arial or 
courier), there would be a total of 52 templates stored for each font type "A," 
representing upper case letters. 



Font jpattem 


Name 


Type 


Description 


Id 


String 


Unique identifier for every font pattern record 


Font_typeJd 


String 


Font type record id which this pattern is a part of 


Name 


String 


Name of the pattern 


Font_data 


Binary 


Image of the font pattern 
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• Ocr form: This table stores infonnation for a form template. It is related to the 
"Ocr cluster" table by a 1-m relation because a form template can have many clusters 
defined within it. It is associated with the "Header" table by a 1-1 relation that links the 
header belonging to a particular form. It is also related to the "Ocr_form_version" table. 
If any information is changed for an existing form template, a new version of it is created 
and a record is set for it in "Ocr form_version" table. 



Ocr Jorm 


Name 


Type 


Description 


Id 


String 


Unique identifier for every form record 


Geojd 


String 


Link to the Geo table for associated state information for a form record 


Headerjd 


String 


Header id for the form header 


Name 


String 


Name of the form (e.g., Texas driver's license) 


Description 


String 


Description if any of the form 


Status 


Integer 


Status of form record to indicate if this fomfi template is the current 
(indicated by 0), added (indicated by 1) or removed (indicated by 2) 
one from the configuration 



• Ocr_form_version: This table is dependent on the "Ocr_form" table and stores 
version information for each form. Included within this table is the X and Y coordinates 
for the starting position of the image under analysis. Thus, if it is known that the first ten 
pixels of a given form image contains information not indicative of the content of the 
form (e.g., because of the rounded comers that exist on the form), these first ten pixels 
can be ignored during OCR. 



Ocr Jbrm^version 


Name 


Type 


Description 


Id 


String 


Unique identifier for every form version record 


Template_package_id 


String 


Template package record id that this form version is a part of 


Ocrform _id 


String 


Form record id which it is a version of 


Version 


Integer 


Version number of this form version 


Xpos 


Integer 


X coordinate of the starting point of the form template 


Ypos 


Integer 


Y coordinate of the starting point of the form template 


Creatorid 


String 


The user id that created this record 


Editor_id 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if this version is active for its parent ocr form 
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1 • Ocr_cluster: This table is dependent on "Ocr_fonn" table and provides a list of 

2 clusters for a particular form. It has 1-m relation with the "Ocr_cluster_version" table 

3 that provides versioning support. As discussed earlier, a cluster is a group of several 

4 elements. Therefore, "Ocr_cluster" is associated with the "Ocr_element" table to provide 

5 a list of necessary elements. 
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Ocr_cluster 


Name 


Type 


Description 


Id 


String 


Unique identifier for every cluster record 


Ocr_form_id 


String 


Form id which this cluster is a part of 


Header_id 


String 


Header id for this cluster 


Name 


String 


Name of the cluster 


Description 


String 


Description of the cluster 



• Ocr_cluster version: "Ocr cluster version" stores the top left and right bottom 
coordinates for the cluster header origin and also stores the cluster header template 
images. Thus, for example, this table is where the cluster header image for the cluster 
containing the date of birth (such as "CLASS:", "DOB:", or the image of the Texas flag) 
would be stored. 



Ocr_cluster_venion 


Name 


Type 


Description 


Id 


String 


Unique identifier for every cluster version record 


Template j3ackage_id 


String 


Template package record id that this cluster version is a part of 


Ocrclusterid 


String 


cluster record id which it is a version of 


Version 


Integer 


Version number of this cluster version 


Name 


String 


Name of the cluster version 


Pointjd 


String 


Starting point (X,Y) for the cluster version template 


Cluster^template 


Binary 


cluster image for this version 


Creatorid 


String 


The user id that created this record 


Editor id 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if this version is active for its parent ocr cluster 



14 
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• Ocr element: This table stores the name and description of particular elements, 
such as date of birth, expiration date, name, etc. It also is related with 
"Ocr_element_version" table through a 1-m relation that provides versioning support. 



Ocrjelement 


Name 


Type 


Description 


Id 


String 


Unique identifier for eveiy element record 


Ocr_clusterJd 


String 


Cluster id which this element is a part of 


Name 


String 


Name of the element 


Description 


String 


Description of the element 



• Ocr element version: The "Ocr_element_version" in effect stores the element 
origins for the various elements within a cluster. Thus, this table stores top left and right 
bottom coordinates ("top_left_id" and "bottom right_id") for sliding a character template 
during OCR analysis, and preferably defines a small rectangle at the upper left comer of 
the character under analysis. In this regard and as disclosed earlier, it has been noted that 
the location of an element within a cluster varies approximately plus-or-minus one pixel 
within the cluster. Therefore, and for example, a small rectangle, perhaps 3-by-3 pixels 
in dimension, is set at the element origin in the test image where it is expected that the 
first character in the element is located. In other words, the small rectangle defines the 
element origin in the test image as a variable region. The upper left pixel of the character 
template is then moved or slid to correspond to one of the nine pixels within the 3-by-3 
pixel rectangle, and a distance metric is calculated for each position. The minimum of 
these nine distance metrics will define the location of the first character of the element 
under analysis. This procedure is then repeated as the sequence estimation algorithm 
sequentially identifies each character in an element. 

Also referenced in this table are the various fonts and pattem specification that are 
to be used for the various elements during OCR analysis. 
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Oct element version 


Nome 


lype 




lU 




UIlllj[uC lUCllllllCl lUi CVCiy ClClllCIll VCIalUll 1CL>U1U 


1 CllipidlC pd^Ka^C lU 




Tpmi^liitp nn/^Vcicrp rpr*ArH \i\ tHat thic pipivipnt vprcirtti ic si f^Jirt /^i 
ICIIlUlalC UaUlVClgC ICUUIU lU UlaL Ulla ClClIlClll VCIslUll 13 A |KUI\J1 


wcr__ioni i>ci__iu 




l^i^nt cpt t*p/^i^f*ri iH Ti^i* t'nic ^\^tw^t\\ vprcinn rp^/^rH 

Fuiii dci recuiu lu lur uub ciciiiciii vcioiuii iccuiu 


P*1pmpnt nsitfpm iH 
iwiviiiCiilLlalidii lu 


OU lllg 


f^lptnpnt nnttpfn iH fnr thiQ pl^mpnt vpixinn rPcnrH 


Ocr_elementJd 


String 


Element record id which it is a version of 


Version 


Integer 


Version number of this cluster version 


Top_left_id 


String 


Top left comer of the element region structure 


Rightbottomjd 


String 


Right Bottom comer of the element region structure 


Creatorjd 


String 


The user id that created this record 


Editorid 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if this version is active for its parent ocr element 



• Element_pattem: The "Element_pattem" table is linked to 
"Element_pattem_character" table with a 1-m relation and is linked to the 
"Ocr_element_version" table with a 1 -m relation. The purposes of the "Element_pattern" 
and "Element_pattem_character" tables are to specify information about the pattern 
specification. For example, in the aforementioned pattem specification representing the 
six-digit date of birth (i.e., N[l:2] N[l:2] N[2:2]), there are five pattem characters 
in the pattem specification, three denoting the month, day, and year (N[l :2] and N[2;2]), 
and two denoting the dashes that separate them ("-"). Thus to create a database 
representation of a six-digit date of birth, one would create a record in the 
"Element_pattem" table with the name of "6-digit date" and then create pattem character 
entries in the "EIement_pattem_character" table, each linking back to the newly created 
"Element_pattem" record. 



Element jattem 


Name 


Type 


Description 


Id 


String 


Unique identifier for every element 


Name 


String 


Description of pattem specification (e.g., "6-digit 
date," "social security number," etc.) 


Creatorjd 


String 


The user id that created tiiis record 


Editorjd 


String 


The user id that edited this record last 


Created 


String 


The date it was created 


Edited 


String 


The date it was last edited 


Active 


String 


Flag representing if this pattem specification is active 
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• Element_pattem_character: The "Element_pattem_character" table stores 
information concerning each pattern character in the pattern specification. Thus, stored 
here are information for each pattern character's character type (e.g., "N" representing 
numbers, or the dash symbol) and length of the pattern character, represented by 
minimum and maximum number of occurrences of the character of that type (e.g., a 
minimum of 1 for the month, and a maximum of 2 for the month). "Seq" stands for 
sequence and denotes the order of the pattern characters within the pattem specification. 
Thus, "Seq" equals 1 for the first pattem character (i.e., N[l:2]), 2 for the second pattem 
character (i.e., "-"), and eventually would equal 5 for the last pattem character (i.e., 
N[2:2]). 



Element j)attem_character 


Name 


Type 


Description 


Id 


String 


Unique identifier for every element pattem character record 


Seq 


Integer 


Identifies the place of a pattem character in it pattem 

specification. 


Element_pattem_id 


String 


Element pattem id for this pattem character record 


Characterjtype 


String 


Describe the type of character (e.g., "N" for numbers, "A" for 
upper case letter, etc. ). 


Min 


Integer 


Minimum character length of the element pattem character 
(e.g., 1 for month or day, or 2 for year). 


Max 


Integer 


Maximum character length of the element pattem character 
(e.g., 2 for month, day, or year) 



• Template_package: This table provides versioning support for all OSU 
configuration components. It stores the version number of latest configuration and also 
the lists for "Header_version," "Ocr_font_set_version," "Ocr_cluster_version" and 
"Ocr_element_version." Note the various tables contain a field called 
"template_package_id" that provides the link or relationship to the "Template_package" 
table. This table is associated with each of these other version tables by a 1-m relation. 



Template _package 


Name 


Type 


Description 


Id 


String 


Unique identifier for every template package record 


Version 


Integer 


Version number of the template package 


Created 


String 


The date it was created 


Active 


String 


Flag representing if this template package is active or not 
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• Tm: This table stores the Visa Net transactions performed for the OSU device 
10. It is linked to "Osu" table through a 1-m relation. 



Tm 








Id 


Qfrinp 


I Ininiip idpnrifler for everv tr!iTi<ifictinn record 


O^ii id 


Ttitpopr 


0<;ii id tn which thi<i transaction record is linked 






Rptiimed reoiiested aiithoriy^ition characteristics indicator 


Store_niimber 


String 


Number assigned by the signing member, processor to identify a 

snecific merchant store within the VisaT^pt svstem 


Terminal niimher 


llllC^d 


Niimher assioned to identifv a iinioiie terminal within a merchant 

l^Ullll/vl QOSlKllvU Wf lU^IIillY U UlllUUv l^ilillllCIl WIUIUI a lllVlVllCUll 

location 


A 1 ith cm ircp 


v^i lui <x\^ ivi 


Source of the authorization code 




IfltAOpr 
iiiic^vi 


Xerminal penerated transaction sentience number 

I VllllillCU gvllvl Ql^U U CUI3CIW11U11 3bUtlVIIVb IIUIIIL^I 


Response code 


String 


Code indicating the status of the authorization request 


Approvalcode 


String 


Authorization code when a transaction has been ^proved 


LocaI_trans_date_time 


String 


Date and time when the transaction took place 


Auth_response 


String 


Response or display text message 


Avs_result 


Character 


Avs Result 


Retrieval_ref_number 


String 


Transaction retrieval reference number returned by the authorizing 
system 


Market_datajdentifier 


Character 


Industry specific data being submitted 


Transjd 


Integer 


Visa transaction identifier or Master Card reference number 


Validation_code 


String 


Specific information generated by the card issuer 


Group_ver 


Integer 


Addendum data group version number 


Committed 


Character 


Flag representing if the transaction has been committed or not 



Whenever the configuration of an OSU device 10 is changed by the vending 
machine operator or Davis system administrator executing an update, a new version for 
that device is created and is added to its version table(s). At the same time, the 
"Template_package" table is updated. When an OSU device 10 connects to the system, 
its current configuration version number is suppHed and is checked against the version 
number present in "Templatejpackage" table. If the number present in the table is 
greater than the one sent by the device, that device requires an update. The latest 
configuration data is then retrieved fi"om the database 70 by reviewing all the version 
tables discussed above. An update package is then created for and sent to the device. If 
the version numbers match, meaning no change is necessary in the configuration of the 
device, the server cluster 1 8 checks to see if a (new) template needs to be added to or 
deleted from that device's configuration file, and again an update package is created and 
sent accordingly. Update packages are created and sent to the devices in a format 
specified by the DTP protocol as explained earlier. 
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1 Control and management of the system occurs at management console 22, which 

2 was explained in some detail earlier. It is from this console that new data is entered onto 

3 the system, such as new or improved templates for the OSU devices 10, or new 

4 configuration updates for the OSU devices 10. Console 22 may also be used to add new 

5 OSU devices 10 to the system. System information may also be retrieved to console 22. 

6 For example, console 22 can obtain updates sent from the OSU devices 10, retrieve a 

7 template list supported by any OSU device 10, or delete templates from an existing OSU 

8 device 10. 

9 Of course, database 70 also preferably includes data files for each of the 

10 consumers who have either pre-registered to use the system, or who have used the 

11 system. Such consumer files may contain important information about the consumer, 

12 such as their names and addresses, information regarding their registered accounts or 
p 13 actual storage of the accounts, and may also 9ontain information that might make 
^ 14 subsequent processing of the consumer's information easier. For example, once a 
gl 15 consumer's date of birth has been assessed, it can be stored. Thereafter, if the system 

16 determines (through OCR) that a particular customer has requested to make a purchase, 

4^ 17 that consumer's file can be analyzed and, for example, the date of birth retrieved, making 

s 

18 fiirther OCR processing of the license potentially unnecessary. 

n 

19 In addition to the table definitions described above, in a commercial system, there 

20 may be over 100 tables in database 70 that are used to support and collect audit data, 

Q 

21 often referred to in the art as DEX or EVA data, and which was briefly discussed earlier. 

22 For more information concerning these DEX related data constructs, the reader is referred 

23 to "European Vending Association Data Transfer Standard," European Vending Association, 

24 Release 5.0, July 1999, which is hereby incorporated herein by reference for all that it 

25 teaches. 

26 B. Update Payload Information 

27 As has been discussed previously, it may be necessary to update the templates or 

28 other configuration information resident in the OSU 6 for optically analyzing a given 

29 license. Below is shown an example of the payload information that is sent by DTP to an 

30 OSU 6 to provide an update to such information, i.e., a Type 7 "Update Response" 

31 packet. This example shows only a representation of the payload of data and does not 
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the Update Response packet. As mentioned earlier, the payload will ultimately be stored 
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ntbpr worHc tbf* navloaH information is oroaniypH in a "tree format " with one data 
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Speciiically, 20 designates and update or addition to sucn iniomiation, while a 21 




29 


designates a deletion. 




30 


Some of the data in the payload is variable in length. For example, the cluster list 




31 


may contain several clusters or only a single cluster. For this reason, the cluster list data 
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1 structure contains at its end an End Of Line ("EOL") marker to denote the boundary 

2 between that data structure and the next data structure in the payload. 

3 Keeping the foregoing in mind, the Update Response payload is preferably 

4 represented as follows. Parenthetical description are used to tie the various data 

5 structures to concepts introduced earlier in this specification: 

6 "Form": 

7 • name (e.g., Texas driver's Ucense) 

8 • "Header" 

9 • "Point" (The reference point for the form. It is the pixel location where 

10 (x,y) = (0,0)) 

1 1 • "Clusterlist" (a list of the clusters within the form) 
12 

1 3 "Header": (represent both form and cluster headers) 

1 4 • name (e.g., 'Texas" or "Texas date of birth") 

1 5 • "Region" (defines the expected location of the header on the form as a 

1 6 rectangle, thus providing the header origin) 

1 7 • header image name (identifies the name of the "Header Image" data 

P 18 structure. I.e., this name points to the correct header image data structure) 

%J 20 "Region": 

Ql 21 • "Point" (top left comer) 

4S 22 • "Point" (right bottom comer) 

f 23 

^ 24 "Pomt": (specifies a particular pixel) 

£ 25 • X (16 bits) 

26 • Y (16 bits) 

ci 27 

28 "Clusterlist": (a list of clusters associated with the form) 

29 • "Cluster 1" 

30 • "Cluster 2" 

31 • "Cluster N", etc. 

32 • "EOL" 
33 

34 "Cluster N": 

35 • "Header" 

36 • "Point" (i.e., the cluster header origin or pixel locate that is remapped to be 

37 (x,y)=(0,0) for the cluster reference point. Offset values for OCR Elements 

38 are calculated relative to this point.) 

39 • "Elementlist" (a list of elements associated with the cluster) 
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1 

2 

3 "Elementlisf : (a list of elements associated with each cluster) 

4 • "Element 1" 

5 • "Element 2" 

6 • "Element N" etc. 

7 • "EOL" 
8 

9 "Element N": 

10 • name (e.g., 6-digit date of birth) 

1 1 • "Region" (defines expected location of the element, i.e., the element 

1 2 origin, with necessary variance as explained earlier) 

13 • "Pattem" 

14 • "Font" (specifies the font type for the element) 

15 

16 "Pattem": (defines the pattem specification) 

1 7 • pattem length (16 bits) (defines the number of pattem characters in the 

18 pattem specification, e.g., 5 for a 6-digit date of birth. Note: this length 
5^ 1 9 obviates the need for an "EOL" marker) 

1^ 20 • "Pattem Character 1" (e.g., the month for the date of birth, i.e., N[l :2]) 

0^ 21 • "Pattem Character 2" (e.g., "-") 

Sj 22 • "Pattem Character N", etc. 

01 23 

42 24 "Pattem Character N": 

~ 25 • "Character Type" (a one byte variable that specifies a particular character 

26 type, e.g., "N" for numbers, "A" for capital letters, etc.) 

27 • number (a one-byte variable that tells the minimum and maximum number 

28 of characters to look in the particular pattem character) 

S 2® 

30 "Header Image": (i.e., the header templates) 

31 • name 

32 • cobium (16 bits) (specifies the number of columns in the template) 

33 • rownum ( 1 6 bits) (specifies the number of rows in the template) 

34 • data (pbcel data) 
35 

36 "Font": 

37 • name 

38 • "Font Type List" 
39 
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1 

2 "Font Type List": (lists the various types of fonts, e.g., Courier 12 pt, Arial 1 0 pt, 

3 etc.) 

4 • "Font Type 1" 

5 • "Font Type 2" 

6 • "Font Type N", etc. 

7 • "EOL" 
8 

9 "Character Type N": 

10 • Type (a byte that specifies the type of characters stored in the associated 

1 1 list. E.g., A = upper case letters (A-Z), a = lower case letters (a-z), N = 

12 numbers (0-9), P = punctuation and symbols e.g., "-/;:! ?0|]{}%$, Z = any 

1 3 upper or lower case letter, X = any letter or number, * = wildcard (any 

14 character, S = space) 

15 • "Character Template List" 
16 

1 7 "Character Template List": 
M 1 8 • "Character Template 1 " (e.g., may represent the template for the number 

O 19 "0" or the letter "A") 

20 • "Character Template 2" (e.g., may represent the template for the number 

p{ 21 "1" or the letter "B") 

?j 22 • "Character Template N", etc. 

23 • "EOL" (null terminated string) 

=P 24 

3 25 "Character Template N": (i.e., the character templates) 

26 • name 

27 • colnum (16 bits) (specifies the number of columns in the template) 

28 • rownum (16 bits) (specifies the number of rows in the template) 



P 

31 



29 • data (pixel data) 



32 V. Modifying a Preexisting Vending Machine to Incorporate an OSU / OSU 

33 Architecture 

34 

35 One of the advantages of the disclosed system is its ability to work with 

36 preexisting vending hardware. Only slight modifications are needed to retrofit such 

37 pieces of equipment with the OSU 6 disclosed herein. How such modifications are made 

38 to a standard vending machine is disclosed as illustrative of this process, but similar 

39 techniques would be used to modify other pieces of equipment, as one skilled in the art 

40 will recognize. The structure, functionality, and operation of such standard vending 

41 machines is also discussed in U.S. patent applications 09/836,805 and 09/851,198, which 
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of the OSU analysis to determine if the condition for purchase (e.g., age) has been met. 
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While the disclosed embodiment shows a traditional vending machine retrofitted 
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disclosure an OSU device 10 from scratch containing an OSU. In such OSU original 
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models, the architecture and circuitry could be arranged in any number of ways to 
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1 achieve suitable functionality, as one skilled in the art will immediately recognize. For 

2 example, it would probably be beneficial in an OSU device 10 designed from scratch to 

3 combine the functionality of the verification controller 93 and the microprocessor 82 into 

4 a single microprocessor, and perhaps to dispense with the use of the microcontroller 230 

5 IMOB bus 96 altogether. Likewise, it may be desirable for the microcontroller 230 to be 

6 positioned outside the OSU, or to reprogram an existing microprocessor 82 to perform 

7 the functions of the microcontroller 230 as disclosed herein. 
8 

9 VL System Installation and Initialization 

10 Suppose a vending machine operator, Bob's Beverages ("Bob"), purchases a 

11 Davis system enabled beverage vending machine equipped with an OSU 6. Bob desires 

12 to sell alcoholic beverages from the machine in a hotel/casino in Las Vegas, Nevada. 
Q 13 Bob, using a web browser on the public internet, e.g., from his interface 20, goes to the 

14 Davis system 8 website and "logs in*' to a secure portion of the site using the user name 

Ql 15 and password that he received either when earlier registering with the system on-line or 

16 when he purchased the machine. Bob then creates a vending machine pool on the 

^ 17 website and adds one machine to it — ^the machine scheduled for delivery to the hotel. He 

|n:!, 18 enters data about the new vending machine to register it with the system, such as its 

19 unique identification number, machine type, location, etc. 

C 20 Bob may then uses the on-line machine configuration editor to set machine and 

Q 

y, 21 OSU 6 operation parameters, i.e.. Bob creates a configuration file for his machine on- 

22 line. For example. Bob may review what types of ID card templates are currently 

23 supported by the system and may select which of those will be accepted by his machine. 

24 Thus, if the system currently supports 100 ID types, including 50 state driver's licenses 

25 type. Bob may choose all ID types or some subset of these to be supported by his 

26 machine. This ID type selection process will allow the templates for the selected ID card 

27 types to eventually be sent by the system to the OSU 6 in Bob's machine. With the 

28 configuration editor. Bob may also configure other functional aspects of his machine. 

29 For example. Bob may specify that periodic audits be scheduled for his machine, e.g., 

30 that DEX/EVA information be sent daily at 2:00am. He may also specify that only 

31 certain product selection window 75 rows will be used to sell age restricted alcoholic 
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1 beverages, and therefore that the consumer's age will need to be verified by the system to 

2 vend products from these rows. He may further configure the system to accept either 

3 cash, coin, and credit card payment methods, and may require credit card information to 

4 be supplied by the consumer to provide further validation of the consumer's identity. 

5 After setting the relevant machine configuration parameters. Bob may now "log out" 

6 from the site. 

7 When the machine arrives at the hotel/casino location, Bob plugs it in and 

8 connects it to a telephone jack. At this point, the OSU 6 in the machine begins an 

9 initialization phase that preferably is factory pre-programmed into the machine, 

10 preferably in Flash 232. The machine accordingly dials a stored phone number to 

11 connect to the Davis system 8, and more specifically and preferably to a designated 

12 initialization computer connected to the system 8. That computer receives the call by 
Q 13 modem, answers it, and notifies a relevant OSU-CS 12 on the system (e.g., one in the 

14 vicinity of the machine) that a connection is being attempted. The OSU-CS 12 attaches to 

01 15 the connection and requests security credentials from the OSU 6, again which are pre- 

"-"4 

^ 16 programmed. The OSU-CS 12 then in secure fashion authenticates the OSU 6 as a new 

vptf 

"t" 17 vending machine for the Bob's Beverages account, e.g., by verifying the ID code for the 

U 18 machine. Thereafter, a connection is established with the server cluster 18, thereby 
O 

1^1^ 19 establishing a "session" as described earlier. The Davis session is responsible for 

20 maintaining dialogue with the OSU 6, via the OSU-CS 12, and for performing services 

yk 21 on behalf of the OSU 6. In this case, i.e., during the initialization phase, the OSU 6 needs 

22 to be updated with the latest software and ID card support. 

23 The OSU 6 makes an "Update Request" to the server cluster 18, which is initially 

24 transmitted to the OSU-CS 12 using the DTP protocol described earlier. The OSU-CS 12 

25 receives the packet and accordingly requests the server cluster 18 to provide a data 

26 structure for the updates. The server cluster 18 in turn creates an EJB (Enterprise Java 

27 Bean, per the Java 2 Enterprise Edition platform defined by Sun Microsystems) to 

28 perform the service. This EJB then accesses system data to create an "Update Response" 

29 packet. During initialization, Bob's previously created configuration file is consulted to 

30 understand the fimctionality that is needed at Bob's machine. For example, in 

31 accordance with the configuration file. Bob may receive the necessary templates to 
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perform template matching and identification for all 50 states, and may receive further 
template data for these states to read and interpret the date of birth on the license to verify 
the consumer's age. The "Update Response" is returned to the OSU-CS 12, which in 
turn repackages the data into a DTP packet and sends the data to the OSU 6 as described 
earlier. The OSU 6 then updates itself with the new data, preferably by storing it in Flash 
232. The server cluster 18 then receives notification from the OSU 6 that the upgrade 
completed successfully. Optionally, the server cluster 18 may send an e-mail to Bob's 
user interface 24 to confirm the completion of the update procedure. 

At this point Bob is ready to stock his machine and put it into operation. Suppose 
a 43-year-old hotel guest from Texas passes by the machine and decides to purchase a 
beer. He makes his selection and is prompted by the display 81 to swipe his credit card 
into credit card acceptor 88 or insert cash into currency acceptor 88. The consumer 
chooses to insert his credit card and then is prompted to insert his driver's license into 
OSU 6. He does so and in a few seconds receives his license back. A few seconds later, 
after locally performing the license and birth identification procedures outlined earlier, 
the display 81 states "purchase successful" and his can of beer is dispensed. By contrast, 
a 17-year-old hotel guest from Colorado passes by the machine and tries to purchase a 
beer. He makes his selection and inserts a five-dollar bill when prompted. He then insert 
his drivers license. After failing the age verification procedure, the display 81 may state 
"Purchase denied. Must be 21 for purchase. Please make another selection." That 
consumer then may select a soda for purchase, or may receive his five dollars back by 
aborting the transaction and selecting a change return option. 

Assume many other purchases are made throughout the day. Then, at 2:00 am the 

next morning, and pursuant to Bob's desires as reflected in his downloaded configuration 

file, the machine dials the server cluster 18 via OSU CS 12 and uploads its DEX 

information. In the morning, Bob checks his e-mail and may find a received message 

from the system 8 saying that his machine was successfiiUy audited. The message also 

preferably provides a link to the audit information. Bob may then click on the link and 

log into the Davis system where he may view the audit report for his new machine. From 

this report Bob may review detailed information concerning each information field 

collected by the DEX feature. For example, he can view information about each 
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1 transaction, he can determine his inventory in the machine, see what product is most 

2 popular, "when" it is most popular, at what price, etc. After one week. Bob generates a 

3 location report to show hotel management how successful the machine has been with 

4 consumers. Based on its success, he receives approval to place one machine on each of 

5 the hotel's 50 floors plus 9 additional units throughout other areas of the hotel and casino. 

6 Bob then purchases, configures, installs, and stocks the new machines as outlined 

7 above, bringing the total of Bob's machines at the hotel to 60. Ultimately Bob may 

8 expand his presence into other regions with many other machines, all of which can be 

9 easily managed and tracked using the disclosed system 8. Importantly, Bob may also 

10 have his machines automatically updated with the latest software and image templates to 

1 1 further improve the functionality of his machine. 
12 

y 14 VIL Other Embodiments 

15 While this disclosure has primarily focused on the vending of age-restricted 

Q) 16 products as an illustrative embodiment, the technology disclosed in the system is capable 

17 of vending other products and services in a reliable and efficient manner, and performing 

a 

M 18 Other useful tasks. 

O 

1^^ 19 An important advantage of the system stems from its ability to treat ordinary ID 

^ 20 cards, such as driver's licenses, as "smart cards," even when those cards do not contain 

M 21 means for electronically holding consumer information, such as magnetic strips or 

22 integrated circuits. In conjunction with the use of a personal identification (PIN) number, 

23 the ordinary driver's license, or any other ID card issued in any jurisdiction, opens the 

24 consumer to an enhanced ability to electronically purchase items and services, and 

25 without the need for vendors to issue specialized and expensive smart cards, which are 

26 usually only useful for purchasing a particular vendor's product. 

27 Thus, the Davis system provides a convenient, low-cost, platform that provides 

28 "smart card" functionality. Furthermore, OSU devices 10 can easily be present at or 

29 incorporated in merchant point-of-sale equipment, building entrances, vending machines, 

30 cars, pay phones, personal computers, gas pimips, and personal data assistants (PDAs), 

31 enabling the consumer to use such devices with only his driver's license or other ID card. 
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1 Indeed, a Davis system may contain several of these types of temiinals (e.g., vending 

2 machines and gas pimips) in one network. 



3 Here are some examples where the disclosed technology is expected to be useful: 

4 • Law Enforcement: A police vehicle equipped with an OSU allows a driver's 

5 license to be scanned. If the system includes or is connectable to a law 

6 enforcement system, information concerning the driver's record could be verified 

7 on the spot, and without the necessity of keying drive license data into a 

8 computer. 

9 • Vehicle Rental: Cars equipped with OSU devices could be rented, perhaps 

10 without the assistance of a rental car attendant. In one embodiment, cars could be 

11 directly equipped with OSUs which communicate with the Davis system by 

12 wireless means. The license could then be verified as valid. Additionally, and if 

13 the consumer does not already have an account on the system capable of paying 

14 for the rental, the consumer could be asked to insert his credit card, either as an 

15 extra validation measure or to pay for the rental or both. Approval of both the 

16 license and the credit card would then allow the car to be started, either 

17 automatically or by tuming the ignition key. (After payment has been arranged, 

18 only insertion of the driver's license would thereafter be necessary to start the 

19 car). Such a system is particularly advantageous because it allows validation of 

20 the driver's license, ensures that the license was not suspended or revoked (if 

21 linked to a law enforcement system), and allows a means for payment via the ID 

22 card, making the rental process a quick and fully automated procedure. As an 

23 alternative, an OSU-equipped vending machine could be used to dispense keys 

24 after license (and perhaps credit card) validation in much the same way. 

25 • Automated Forms Processing: Standard forms, such as insurance cards, could be 

26 scanned in order to automate data entry of the information contained thereon. 

27 Manual data entry is by comparison slow and error prone. 

28 • Security Card: High security areas, such a building entrances, parking garages, 

29 certain rooms within a building, etc., when equipped with an OSU, would allow 

30 or disallow access (e.g., by locking or unlocking doors or gates) merely upon an 
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assessment of a driver's license, and without the need to issue special access 
cards. 

Check Cashing/Credit Card Transactions: OSU devices 10 connected to the Davis 
system could be used as an extra security check to verify the identity of those 
presenting licenses to support the cashing of a check or those using credit cards to 
make a purchase. 

Gas Pumps: A gas pump equipped with an OSU could not only be used to vend 
the gas and pay for the purchase, but could also allow the license to be checked 
for validity if interfaced with an appropriate law enforcement system. If the 
consumer's license is determined not to be valid or has been suspended or 
revoked, the purchase could be disabled, with the tangential benefit of keeping 
unlicensed drivers from driving. Additionally, the system could be progranuned 
to receive periodic updates (e.g., daily) from the law enforcement system 
concerning license status (suspended, revoked, valid), which could then be stored 
in database 70. In this embodiment, the system would not need to query the law 
enforcement system each time a consumer made a purchase request, but could 
instead maintain a file on database 70. 

Validation of Passports and Visas: If the OSU devices 10 were fitted with flat bed 

scanners, or a modified version of the OSU 6, they could be used to allow 

passports and visas to function in much the same way as driver's licenses or other 

ID cards as disclosed herein. Thus, customs or other officials could employ such 

OSU devices 10 to verify such information on the spot for travelers and other 

persons. Thus, the Davis system to which the OSU devices are connected could 

be connected to government agency databases to verify that the passport or visa is 

valid, contains the correct information, and has not been tampered with. In such 

an application, the OSU could be used to determine, by OCR, the traveler's name, 

and this name could be sent by the system to a government agency database, to 

pull other desired information for the individual, such as his immigration status. 

Additionally, and in conjunction with the proper database, background or criminal 

checks could be run. If necessary, the photo on the passport or visa (if any) could 

be sent in real time to personnel at these agencies for a manual photo check. This 
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may be useful in the apprehension of terrorists, missing persons, and criminals. 
Additionally, future technologies may allow for passport photos to be pre-scanned 
and stored, possibly allowing template matching of the faces stored on the 
scanned and stored ID photos. 

Locating Criminals: In another embodiment, certain drivers containing suspended 
or revoked licenses, or which have criminal records, could have their licenses "hot 
listed" in the system by law enforcement officials. When such licenses were used 
at any OSU device 10 connected to the system, special procedures could be put in 
place by the system which would immediately notify law enforcement agencies of 
the time, date and location in which the purchase was completed or attempted, 
with the hope that such persons could more easily be brought to justice. 
Additionally, such information could be stored in the system and made accessible 
for law enforcement officers to review at their leisure. Such an OSU device 10 
might be especially well-suited for installation at airports, where passenger 
identities could be verified. Thus, when a passenger checks in at the airport he 
would be required to insert his drivers license into an OSU device 10, which in 
turn could be connected to a national database to check if the person was on a 
"watch list." 

License plate capture: In another embodiment, an automobile license plate image 
could be captured and processed. An OSU 6 can be embedded with or connected 
to an image capturing device, such as a video camera or motion-sensitive still 
image camera. Using such a device, license plates could be optically captured by 
law enforcement officers (e.g., to nab speeding drivers) and automatically 
processed to tap into information databases containing, for example, vehicle 
registration information. Such a device could also be used in parking garages to 
capture information about who is entering and exiting the garage, or to authorize 
access. 

Tamper-proofing Photos: In another embodiment, an ID card photo image can be 

compared with the original photo when the ID card was created. After a person is 

issued an ID card, the image is stored in an database connected to a Davis system. 

As the person uses the card m an OSU device, the two are compared. Specific 
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1 points or the entire image can be compared to determine if the image has been 

2 significantly altered. 

3 As well as having other uses, the disclosed system may be implemented in a 

4 number of different ways depending on the desired system functionality. Databases 

5 and/or servers could be combined with OSU devices. Other components disclosed herein 

6 as being integrated could also be separated if desirable. The specific hardware 

7 components could be easily changed or altered by those of ordinary skill. Furthermore, 

8 the system may be used to vend a wide array of products and services. For example, 

9 some of the OSU devices 10 could be configured to vend age-restricted products, while 

10 other OSU devices 10 on the system could be configured to act as ATMs, security 

11 monitors, gas pumps, etc. The disclosed system therefore has great flexibility. 

12 Moreover, the use an OSU is not strictly necessary to realize some of the benefits 



Q 13 that are disclosed herein. Other suitable means for receiving consumer information, e.g., 

^ 14 such as by computer or keypad, or through electronic means such as by credit cards 

Ql 15 containing magnetic strips or smart cards containing integrated circuitry, may be useful in 

g=j 16 certain novel aspects as disclosed herein. In this vein, it should be noted that the 

17 disclosed systems and associated methods are believed to be patentable in several 

H 18 different respects, and with respect to several of its components and/or subcomponents, 
Q 

19 even if the benefits of these other inventive aspects have not been specifically touted in 

^ 20 this specification. 

21 The concept of storage of data within a memory refers to storage in any suitable 

22 means for retaining digital data, such as in a memory chip or on a magnetic disk. 

23 References to muhiple memories in the appended claims, such as a first memory and a 

24 second memory, should be understood as referring generally to storage in separate 

25 discrete memory devices, or storage on a single device in different memory locations, 

26 registers, or blocks within the same memory device. 

27 From the foregoing detailed description of specific embodiments of the invention, 

28 it should be apparent that a system and associated methods for vending products and 

29 services using an identification card has been disclosed. Although specific embodiments 

30 of the invention have been disclosed herein in some detail, this has been done solely for 

31 the purposes of illustrating various aspects and features of the invention, and is not 
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1 intended to be limiting with respect to the scope of the invention. It is contemplated that 

2 various substitutions, alterations, and/or modifications, including but not limited to those 

3 design alternatives which might have been specifically noted in this disclosure, may be 

4 made to the disclosed embodiment without departing from the spirit and scope of the 

5 invention as defined in the appended claims. 
6 
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